[02:42] <imbrandon> quiet evening :)
[08:59] <Laney> we fixed all the bugs already!
[12:02] <directhex> ricotz, did you upload docky 2.1.3 to ubuntu?
[12:32] <ricotz> directhex, i requested a sync, so if you want to upload it go ahead
[14:01] <xdatap1> hello Guys. Just a curiosity. What's the meaning of row colors on merges.ubuntu.com? Like here: https://merges.ubuntu.com/main.html
[14:01] <tumbleweed> package priority, IIRC
[14:02] <geser> I remember the same
[14:02] <xdatap1> thanks :)
[14:04] <tumbleweed> geser: btw, I see you wrote the code behind qa-ftbfs. I've been playing with getting it to grah FTBFS-quantity history. Are you taking patches?
[14:04] <tumbleweed> http://corelli.tumbleweed.org.za/ubuntu-qa/qa-ftbfs/oneiric-historical.html
[14:05] <geser> sure, and nice graphs
[14:05] <tumbleweed> only been collecting data for two days (and end of natty), so not much yet
[14:11] <tumbleweed> geser: lp:~stefanor/+junk/qa-ftbfs (Maybe move from +junk to an ubuntuwire project on lp?)
[14:22] <geser> tumbleweed: good idea, do you know who I've to talk about it? wgrant?
[22:57] <Laney> anyone got a ppc/oneiric or sid chroot? Please try installing ghc and see if /usr/bin/ghci works (gets you a prompt)
[22:58] <tumbleweed> Laney: I have (both, I think)
[23:01] <tumbleweed> Laney: but not very useful: ghc: timer_create: Function not implemented
[23:01] <tumbleweed> that could be qemu's fault
[23:01] <tumbleweed> (it's surrounted by Unsupported syscall: 240s)
[23:04] <Laney> ah ok
[23:06] <tumbleweed> powerpc is only sort-of usable on qemu. One can debug some issues, that's it
[23:06] <tumbleweed> #debian-ppc ?
[23:07] <stgraber> Laney: I'm testing it now
[23:07] <Laney> just want to confirm a bug
[23:07] <Laney> he reported it on ppc64
[23:08] <stgraber> Laney: http://paste.ubuntu.com/629576/
[23:08] <stgraber> Laney: segfault
[23:08] <Laney> ta
[23:08] <Laney> that is what the bug said too


 snow snow snow snow!
[19:54] <valorie> nice! a couple of days late, but still!
[19:54] <valorie> cool and sunny here
[19:54] <valorie> it was 28F when I first awoke
 Snow near Christmas is still an 'event' here, so was nice :)
 I don't exactly like the snow right now heh.


[06:08] <mborzecki> morning
[07:02] <pedronis> mborzecki: hi, is this known https://bugs.launchpad.net/snapd/+bug/1853512 ?
[07:02] <mup> Bug #1853512: snapd can't be installed on Centos 8 <snapd:New> <https://launchpad.net/bugs/1853512>
[07:21] <mborzecki> pedronis: that would be unexpected, thought snapd would be rebuilt automatically
[07:22] <mborzecki> Eighth_Doctor: wouldn't snapd get and automatic rebuild when selinux-policy-base gets a bump?
[07:27] <mborzecki> pedronis: i need to prep an update to 2.42.2 so we'll get a rebuild anyway
[07:27] <pedronis> ok
[07:28] <pedronis> mborzecki: I assigned it to you
[07:28] <mborzecki> pedronis: ok
[07:33] <mup> Bug #1484641 changed: snappy config command does not restart service after setting the configuration <Snappy:Won't Fix> <https://launchpad.net/bugs/1484641>
[07:34] <Eighth_Doctor> mborzecki: no
[07:35] <mborzecki> Eighth_Doctor: it's because the snapd-policy is outside of EPEL right?
[07:35] <Eighth_Doctor> no
[07:35] <Eighth_Doctor> it's because the Fedora build system can't do that
[07:35] <Eighth_Doctor> it can't auto-submit a rebuild
[07:36] <mborzecki> Eighth_Doctor: meh :P where do i submit the PRs?
[07:41] <pedronis> mborzecki: mvo:  https://api.travis-ci.org/v3/job/615952834/log.txt  gadget-update-pc seems to have a real issue
[07:41] <mborzecki> pedronis: should be a quick fix
[07:48] <zyga> good morning
[08:00] <pstolowski> morning
[08:02] <zyga> hey Paweł
[08:04] <pedronis> pstolowski: hi, what's blocking the preseed PRs, lack of reviews ?
[08:05] <pstolowski> pedronis: yes
[08:11] <pstolowski> pedronis: #7706 and #7658 are closest to be landdable i think
[08:11] <mup> PR #7706: overlord/snapstate: install task edges <Preseeding 🍞> <Created by stolowski> <https://github.com/snapcore/snapd/pull/7706>
[08:11] <mup> PR #7658: cmd/snap-preseed: add snap-preseed executable <Preseeding 🍞> <Created by stolowski> <https://github.com/snapcore/snapd/pull/7658>
[08:11] <pedronis> pstolowski: I will switch to do more reviewing this week
[08:11] <pedronis> mborzecki: are you working on fixing that gadget-update-pc issue?
[08:12] <pedronis> pstolowski: a 2nd review for #7774 would be great
[08:12] <mup> PR #7774: seed: proper support for optional snaps for Core 20 models <Created by pedronis> <https://github.com/snapcore/snapd/pull/7774>
[08:14] <pstolowski> pedronis: sure, looking at it
[08:15] <pedronis> thx
[08:15] <mborzecki> pedronis: yes
[08:16] <pedronis> thank you
[08:31] <mup> PR snapd#7774 closed: seed: proper support for optional snaps for Core 20 models <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/7774>
[08:32] <pstolowski> dot-tobias: hello! was that you who reported and intended to work on a fix for https://bugs.launchpad.net/snapd/+bug/1851480 ?
[08:32] <mup> Bug #1851480: Hooks are not included in slot/plug label expressions <snapd:Confirmed for glancr> <https://launchpad.net/bugs/1851480>
[08:37] <mborzecki> heh, so core18 gadget-update test fixed, but fails on core16 now, because core18 uses pc=18, but core16 just pc, perhaps the update of gadget.yaml should be done in yaml-aware way, rather than by swapping the text file
[08:38] <pedronis> mborzecki: pc for 18 has a track, pc latest is really 16
[08:39] <pedronis> so that part of the tests is right
[08:40] <mborzecki> pedronis: right, 18/edge contains some extra entries that aren't in latest
[08:40] <pedronis> might need to talk with mvo/foundations about them
[08:41] <zyga> brb, 2nd coffee needed
[08:41] <mborzecki> pedronis: the test should account for that, so as far as i'm concerned the test needs fixing
[08:41] <pedronis> mborzecki: sounds it need different reference info for 18 vs 16 ?
[08:44] <mborzecki> pedronis: pyyaml is in core*,
[08:44] <mborzecki> pedronis: so i might just generate gadget.yaml's on the fly
[08:47] <pedronis> pstolowski: reviewed 7706, let me know if the comment abou edge names make sense
[09:03] <pstolowski> pedronis: yes, i get your point, makes sense, thx
[09:10] <pedronis> pstolowski: I did another pass on 7658, minor things
[09:10] <pstolowski> thank you!
[09:20] <mup> PR snapd#7782 opened: osutil: handle "rw" mount flag in ParseMountEntry <Simple 😃> <Created by zyga> <https://github.com/snapcore/snapd/pull/7782>
[09:34] <mup> PR snapd#7727 closed: tests: improve TestDoPrereqRetryWhenBaseInFlight to fix occasional flakiness <Test Robustness> <Created by stolowski> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/7727>
[09:37] <Chipaca> brb, coffee break
[09:47] <mup> PR snapd#7783 opened: osutil/mount: add {Unm,M}outFlagsToOpts helpers <Simple 😃> <Created by zyga> <https://github.com/snapcore/snapd/pull/7783>
[09:48] <mup> PR snapd#7770 closed: testutil, many: make MockCommand() create prefix of absolute paths <Simple 😃> <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/7770>
[09:54] <mup> PR snapd#7784 opened: cmd/snap-update-ns: adjust debugging output for usability <Created by zyga> <https://github.com/snapcore/snapd/pull/7784>
[09:57] <zyga> mborzecki: are you onto that master-broken thing?
[09:57] <mborzecki> zyga: yes, opening it in a bit
[09:58] <zyga> great, thank you
[10:07] <mup> PR snapd#7785 opened: tests/main/gadget-update-pc: use a program to modify gadget yaml <Test Robustness> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7785>
[10:07] <mborzecki> zyga: pedronis: ^^ should unbreak master
[10:08]  * zyga looks too
[10:08] <mborzecki> wish there was a way for pyyaml to preserve the structure of the document
[10:10] <zyga> mborzecki: reformat with black please
[10:10] <zyga> it's a good default
[10:10] <zyga> and seems to be adopted across canonical now
[10:12] <pedronis> mborzecki: thanks, reviewed
[10:17] <mborzecki> zyga: pedronis: thanks, i'll push those in a followup if you don't midng
[10:28] <zyga> not at all
[10:50] <mup> PR snapcraft#2815 closed: minor developer env/doc updates <Created by cjp256> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2815>
[10:56] <pedronis> mborzecki: it's fine, as I as much in the review
[10:56] <pedronis> s/as I as/I said as/
[10:56]  * Chipaca sets up a synchrotron in a cave to make antichampagne
[11:06] <mvo> Chipaca: lol
[11:08] <mup> PR snapcraft#2803 closed: snap: add license to snapcraft.yaml <Created by sparkiegeek> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2803>
[11:53] <pedronis> mvo: zyga: https://github.com/snapcore/snapd/pull/7773 will the feature flag be only for 2.42 ? did you discuss that again?
[11:53] <mup> PR #7773: cmd/snap-update-ns: fix overlapping, nested writable mimic handling <Needs Samuele review> <⚠ Critical> <⛔ Blocked> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7773>
[11:54] <mvo> pedronis: if everyone feels its safe to include it in 2.42 as is I'm fine with that - otherwise I think we want this behind a feature flag
[11:54] <mvo> pedronis: wdyt?
[11:55] <pedronis> mvo: my main input is that the feature flag doesn't make sense on master, it's fix that we want to test
[11:56] <pedronis> mvo: I would like to understand what we think makes it not safe
[11:57] <pedronis> it's a fairly global change, so if it's not safe, it's probably not safe very generally
[12:00] <zyga> pedronis: I think mvo's concern was that it will have extremely limited testing
[12:01] <zyga> pedronis: and for the point release it would be safer to put it behind a feature flag
[12:01] <zyga> pedronis: so that it can be exposed to the customer that needs to use it
[12:01] <zyga> pedronis: the next regular release can enable the feature flag if unset
[12:01] <zyga> pedronis: so that it goes through regular testing
[12:01] <pedronis> something doesn't add up for me
[12:01] <mvo> pedronis: yeah, it's fine for master but I'm a bit concerned that it's too invasive for a point release
[12:03] <zyga> pedronis: can you be more specific?
[12:04] <pedronis> zyga: the change has two parts, one is turning keeping into unmount/mount, either we are ok with that or we aren't ?
[12:05] <pedronis> the other ignoring some errors, that is more worrying, but it's a bit unclear if a feature flag will help with that or not. what sanity/safety are we losing here?
[12:06] <zyga> pedronis: I think we are fine with both of those (the error is ignored for a specific reason) but the fact that it will get limited testing before hitting stable (AFAIK 2 days) is why mvo wanted to avoid the chance that we missed something and it is indeed unsafe.
[12:06] <zyga> pedronis: as for testing, I will work to make sure that both unit and spread tests cover both variants for now
[12:07]  * mvo is in a meeting, sry!
[12:07] <zyga> pedronis: and for the next release we can change the default-if-unset to true so that everyone gets the new, improved behavior
[12:07] <zyga> pedronis: and given that it will be tested over a cycle, we can release that with more confidence
[12:08] <pedronis> zyga: will need also to disuss another rewrite of update-ns, I'm not a fan of the ignoring the error bit going forward
[12:08] <zyga> at least that's how I understood mvo's concerns
[12:08] <zyga> pedronis: that's fine, we understand how to make that possible, it's just larger in scope
[12:09] <zyga> pedronis: note that ignoring the error is only safe when both patches are used
[12:10] <pedronis> mborzecki: what's the status of #7732 ?
[12:10] <mup> PR #7732: [PoC] many: extracted snaps mode <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7732>
[12:11] <mborzecki> pedronis: we can close it, it was a temporary hack for ijohnson to try
[12:12] <mup> PR snapd#7732 closed: [PoC] many: extracted snaps mode <Created by bboozzoo> <Closed by pedronis> <https://github.com/snapcore/snapd/pull/7732>
[12:12] <pedronis> zyga: I'm worried of the added messiness in terms of tests and code of the flag, that's why I'm not a fan of having it on master
[12:13] <zyga> pedronis: I see
[12:13] <mborzecki> heh, #7785 is red, i can push a followup patches there anyway now
[12:13] <mup> PR #7785: tests/main/gadget-update-pc: use a program to modify gadget yaml <Test Robustness> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7785>
[12:13] <zyga> I wonder if we could avoid that entirely with a snapd-from-branch
[12:13] <zyga> so that the customer could use snapd from a branch and upgrade to stable on the regular cycle
[12:13] <zyga> is that possible today?
[12:14] <pedronis> in principle yes
[12:17] <pedronis> pstolowski: given that #7320 and 7744 are related, you should probably pick up the former from John
[12:17] <mup> PR #7320: snap/pack, cmd_pack: 'snap pack --check-skeleton' checks interfaces <Needs Samuele review> <Created by chipaca> <https://github.com/snapcore/snapd/pull/7320>
[12:18] <Chipaca> pedronis: you meant 7744?
[12:18] <pedronis> heh, not I meant 7740
[12:18] <Chipaca> phew :)
[12:23] <pstolowski> pedronis, Chipaca: sure, i can take it
[12:47] <mup> PR snapd#7777 closed: snap-confine: suppress noisy classic snap file_inherit denials <Created by jdstrand> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/7777>
[13:01] <mup> PR snapd#7785 closed: tests/main/gadget-update-pc: use a program to modify gadget yaml <Test Robustness> <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/7785>
[13:02] <mborzecki> master should be unblocked now
[13:06] <pedronis> mborzecki: great, thanks
[13:12] <mup> PR snapd#7786 opened: many: make ValidateBasesAndProviders signature simpler/canonical <Created by pedronis> <https://github.com/snapcore/snapd/pull/7786>
[13:13] <pedronis> that's a small tweak ^
[13:14] <pedronis> #7775 is also ready for review (been rebased)
[13:14] <mup> PR #7775: seed: support extra snaps on top of Core 20 dangerous models <Created by pedronis> <https://github.com/snapcore/snapd/pull/7775>
[13:29] <cachio> mborzecki, hey
[13:29] <mborzecki> cachio: hey, what's up ?
[13:29] <cachio> I see the test gadget-update-pc is failing
[13:29] <cachio> the pc-gadget.yaml on the test seeems to need an update
[13:30] <cachio> mborzecki, https://travis-ci.org/snapcore/snapd/jobs/616564112#L3392
[13:31] <cachio> mborzecki, can you confirm that?
[13:31] <mborzecki> cachio: the fix landed half an hour ago :)
[13:32] <cachio> mborzecki, ahhh, nice
[13:41] <zyga> brb
[13:41] <zyga> thank you for fixing master mborzecki
[14:05] <mup> PR snapd#7721 closed: gadget: add support for hybrid partitioning schemas <Simple 😃> <⛔ Blocked> <Created by bboozzoo> <Closed by bboozzoo> <https://github.com/snapcore/snapd/pull/7721>
[14:08] <mup> PR snapcraft#2821 opened: meta: remove __dict__ usage in Snap  <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/2821>
[14:45] <ijohnson> zyga: thanks for the response on that post, just read it and it all makes sense, I just wasn't sure if there was some deeper reason to that limitation or not
[14:46] <zyga> ijohnson: the deeper reason is: we didn't anticipate it I guess
[14:46] <zyga> ijohnson: as for the 200 ms optimization
[14:46] <zyga> ijohnson: I think it's worth it for reliability and simplicity
[14:46] <ijohnson> yah I don't think it's worth it right now
[14:46] <zyga> ijohnson: also, we could change the way themes are used using tmpfs layout instead of mimic
[14:47] <ijohnson> just something I wanted to bring up mostly so we don't forget about it later :-)
[14:47] <zyga> one layout, many content connections == more explicit and obvious as to what is going on
[14:47] <ijohnson> hmm interesting point about the many themes
[14:47] <ijohnson> I don't have the numbers with me, but IIRC when I tested the various permutations of layouts and themes, the big time we spend right now for these snaps is in the layouts, not in the themes
[14:48] <zyga> yeah but it's all one thing
[14:48] <zyga> not two things
[14:48] <zyga> if we can change $anything to avoid the need to use mimics it will both be simpler to understand and faster
[14:48] <ijohnson> the themes results in a lot of mounts, but not a lot of computation (i.e. total speedup from removing themes wasn't measurable, but removing the mimics was)
[14:48] <ijohnson> yes agreed
[14:48] <ijohnson> mimics == complicated and slow
[14:49] <ijohnson> (relatively speaking)
[14:50] <zyga> yes
[15:22]  * cachio lunch
[15:37] <jdstrand> roadmr: hi! can you pull 20191125-1519UTC? note, I'm off Wed-Fri
[15:37] <roadmr> jdstrand: sure! so am I, heh, so no guarantees it'll be rolled out before Monday, but I'll try to leave everything merged and QAd so someone else can action that
[15:38] <jdstrand> roadmr: monday rollout seems reasonable since we are off
[15:48] <Chipaca> saw a tweet just now and thought "ooh, they're using snaps at nasa?"  … https://www.theregister.co.uk/2019/11/25/space_roundup/
[15:48] <Chipaca> (short answer: mu)
[15:54] <pstolowski> ijohnson: hey, would you find a moment for \https://github.com/snapcore/snapd/pull/7740 ?
[15:54] <mup> PR #7740: overlord/ifacestate: report bad plug/slots with warnings on snap install <Needs Samuele review> <Created by stolowski> <https://github.com/snapcore/snapd/pull/7740>
[16:03] <mup> PR snapcraft#2818 closed: project: pivot `info` from ProjectInfo to Snap <Created by cjp256> <Closed by cjp256> <https://github.com/snapcore/snapcraft/pull/2818>
[16:12] <mup> PR snapd#7744 closed: snap-bootstrap: set expected filesystem labels <uc20> <Created by cmatsuoka> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7744>
[16:17]  * Chipaca shakes fist at universe and goes for a cuppa tea
[16:19] <pedronis> a 2nd review for #7786 would be great (it's small)
[16:19] <mup> PR #7786: many: make ValidateBasesAndProviders signature simpler/canonical <Created by pedronis> <https://github.com/snapcore/snapd/pull/7786>
[16:21] <pstolowski> pedronis: https://github.com/snapcore/snapd/pull/7780 can land
[16:21] <mup> PR #7780: tests: cleanup most test snaps icons, they were anyway in the wrong place <Created by pedronis> <https://github.com/snapcore/snapd/pull/7780>
[16:22] <mup> PR snapd#7786 closed: many: make ValidateBasesAndProviders signature simpler/canonical <Created by pedronis> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7786>
[16:22] <pedronis> thx
[16:22] <Chipaca> pedronis: +1
[16:22] <Chipaca> heh, that
[16:23] <pedronis> cachio: can you give a quick look at #7780 fyi
[16:23] <mup> PR #7780: tests: cleanup most test snaps icons, they were anyway in the wrong place <Created by pedronis> <https://github.com/snapcore/snapd/pull/7780>
[16:24] <mup> PR snapd#7781 closed: seed: fix confusing pre snapd dates in tests <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/7781>
[16:25] <mup> PR snapd#7780 closed: tests: cleanup most test snaps icons, they were anyway in the wrong place <Created by pedronis> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7780>
[16:26] <mup> PR snapd#7753 closed: po: sync translations from launchpad <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7753>
[16:28] <mvo> yay, below 70!
[16:28] <mup> PR snapd#7740 closed: overlord/ifacestate: report bad plug/slots with warnings on snap install <Needs Samuele review> <Created by stolowski> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7740>
[16:33] <mup> PR snapd#7787 opened: many: share single implementation to list needed default-providers <Created by pedronis> <https://github.com/snapcore/snapd/pull/7787>
[16:41] <ijohnson> pstolowski: sure it's on my queue, should get to it in my PM
[16:42] <ijohnson> pstolowski: hmm seems I was too slow and mvo already approved/merged it :-)
[16:42] <pstolowski> ijohnson: hah, indeed, mvo was faster :)
[16:42] <pstolowski> anyway, thanks, both of you :)
[16:57] <mvo> my pleasure
[17:16] <mup> PR snapd#7788 opened: overlord/snapstate: pick up system defaults when seeding the snapd snap <⚠ Critical> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7788>
[17:17] <mborzecki> pedronis: ^^
[17:17] <mborzecki> wrapping it up, need to go and pick up the kids from some extra classes and help out with the homwork a bit
[17:26] <sdhd-sascha> is it correct, the the build base here is core20 ? https://github.com/snapcore/core20/blob/master/snapcraft.yaml
[18:02] <sdhd-sascha> Just found, how to build an image: https://discourse.ubuntu.com/t/building-multipass-images-with-packer/12361
[18:03] <sdhd-sascha> Hope i will find the source, for the core20 multipass image... 😶
[19:30] <ijohnson> hey diddledan, you around? got a question for you about https://github.com/diddlesnaps/supertuxkart/blob/master/libopenh264-helper/libopenh264/library-exports
[20:21] <ijohnson> ugh github is being slow/is down
[20:36] <Chipaca> sdhd-sascha: what are you trying to do with core20?
[21:00] <sdhd-sascha> just want to see if the eoan 19.10 packages from sway, would run inside of a snap. I know i could create a squash, or use the same patches, etc... I figured out, that the core18 is the same as ubuntu-core-18-amd64.img... Know i need to know how to add the image into multipass. Then i found that inside _multipass.py:46 is core18 and core...
[21:05] <sdhd-sascha> i mean, add sway as stage-package and do a black box comparison. Chipaca:
[21:05] <sdhd-sascha> Chipaca: ;-)
[21:11] <sdhd-sascha> The problem is that sway, with sys_cap_admin and suid inside the snap, do so many fork's and execv.. calls, that somewhere the environment goes away (LD_LIBRARY_PATH). And "strace -f" hangs if sway is started with this privileges. But the current version of eoan (debian) has some patches, where no suid and no "setcap" is needed. So i would just try if the eoan packages would work. I don't want to do a dist-upgrade
[21:11] <sdhd-sascha> inside of core18. Maybe a apt-build...
[21:13] <sdhd-sascha> have also considered sway linking static, then the LD_LIBRARY_PATH does not matter.
[21:18] <sdhd-sascha> yesterday i build wlroots as meson-subprojects, which has the affect, that systemd was recognized. (didn't tested to start sway over systemd yet... this should work without cap's)
[21:18] <sdhd-sascha> And i experiment with dbgsym's inside of's snap's because at some stage the my kms/drm drivers crashed on start from tty.
[21:18] <sdhd-sascha> Chipaca: and so on ... :-D
[21:20] <Chipaca> ah, the weird compositor that needs crazy capabilities
[21:20] <Chipaca> o...k :)
[21:20]  * Chipaca isn't running that any time soon
[21:23] <sdhd-sascha> Well, back to my question. Did i need patch snapcraft or multipass? Or can i just add the daily cloud-images from ubuntu.com somewhere and install snapcraft-edge ...
[21:23] <sdhd-sascha> But, is ok. I could also figure it out, sometime
[22:28] <sdhd-sascha> Chipaca: I have to go the other way yet. Unless I want to build the ubuntu-core images myself. 'Cause the CI/CD doesn't produce the needed images for multipass... https://github.com/CanonicalLtd/multipass/pull/1192
[22:28] <mup> PR CanonicalLtd/multipass#1192: add core20 image urls <Created by sd-hd> <https://github.com/CanonicalLtd/multipass/pull/1192>
[22:35]  * cachio afk


[14:27] <sarnold> good morning
[14:30] <joalif> o/
[14:30] <slyon> o/
[14:31] <didrocks> hey
[14:31] <cpaelzer> OMW
[14:31] <cpaelzer> one sec ...
[14:34] <cpaelzer> now I'm hgere
[14:34] <cpaelzer> too many conflicting meetings
[14:34] <cpaelzer> thanks for your patience
[14:34] <cpaelzer> #startmeeting Weekly Main Inclusion Requests status
[14:34] <meetingology> Meeting started at 14:34:57 UTC.  The chair is cpaelzer.  Information about MeetBot at https://wiki.ubuntu.com/meetingology
[14:34] <meetingology> Available commands: action, commands, idea, info, link, nick
[14:35] <cpaelzer> Ping for MIR meeting - didrocks joalif slyon sarnold cpaelzer jamespage
[14:35] <cpaelzer> #topic current component mismatches
[14:35] <cpaelzer> Mission: Identify required actions and spread the load among the teams
[14:35] <cpaelzer> #link https://people.canonical.com/~ubuntu-archive/component-mismatches-proposed.svg
[14:35] <cpaelzer> #link https://people.canonical.com/~ubuntu-archive/component-mismatches.svg
[14:35] <cpaelzer> let us see if we have anything new in there to act on
[14:35] <slyon> nothing new AFAICT
[14:35] <cpaelzer> yep, I still ping jamespage / coreycb for jaraco every week
[14:35] <cpaelzer> but indeed all in there are known cases
[14:35] <cpaelzer> \o/
[14:36] <sarnold> \o/
[14:36] <cpaelzer> #topic New MIRs
[14:36] <cpaelzer> Mission: ensure to assign all incoming reviews for fast processing
[14:36] <cpaelzer> #link https://bugs.launchpad.net/ubuntu/?field.searchtext=&orderby=-date_last_updated&field.status%3Alist=NEW&field.status%3Alist=CONFIRMED&assignee_option=none&field.assignee=&field.subscriber=ubuntu-mir
[14:36] <cpaelzer> https://bugs.launchpad.net/ubuntu/+source/webp-pixbuf-loader/+bug/1979121
[14:36] <cpaelzer> just this one
[14:36] <cpaelzer> marked low prio and no milestone
[14:36] <cpaelzer> so it might be non-urgent, but I havne't read the details
[14:37] <coreycb> cpaelzer: re: jaraco. I think that's ready for main (?)
[14:37] <sarnold> there's text in the bug that asks for august 25
[14:37] <cpaelzer> coreycb: jaraco.text is in, but it depends on jaraco.context which has no MIR assigned
[14:37] <slyon> "The package webp-pixbuf-loader is required in Ubuntu main no later than aug 25 due to feature freeze"
[14:37] <cpaelzer> indeed sarnold, I set the milestone accordingly
[14:37] <sarnold> thanks
[14:38] <cpaelzer> looking for a review volunteer on webp
[14:38] <coreycb> cpaelzer: https://bugs.launchpad.net/ubuntu/+source/jaraco.context/+bug/1975600
[14:38] <cpaelzer> reading coreycb ...
[14:38] <cpaelzer> coreycb: it didn#t have the MIR team subscribed
[14:38] <cpaelzer> fixed it
[14:38] <coreycb> ahh ok, thanks!
[14:39] <cpaelzer> now you need an AA to promote it
[14:39] <cpaelzer> I can take that for tomorrow
[14:39] <didrocks> I can have a look, but this is desktopish and it’s always a little bit off for me to ask a manual test plan (that again, we don’t have here as a wiki page :/)
[14:39] <coreycb> cpaelzer: great, thank you
[14:39] <cpaelzer> I haven't done a graphic MIR in a while I also take webpm
[14:39] <didrocks> so having another pair of eye would be better to reenforce that this is 1. a fallback plan and 2. not optional
[14:40] <cpaelzer> I will didrocks, thanks for the hint
[14:40] <sarnold> no tests for an image loader? :(
[14:41] <cpaelzer> TBH I've seen plenty of image loader tests - like convert from A->B and then check expected output
[14:41] <cpaelzer> is webp non deterministic?
[14:41] <didrocks> even non determinstic, you can add fuzzy comparison…
[14:41] <cpaelzer> like could it produce slightly different output on the panel it draws to every time?
[14:41] <sarnold> on the other hand, a package without tests can't possibly be broken..
[14:41] <cpaelzer> lol
[14:41] <didrocks> until people are using it? :p
[14:41] <cpaelzer> very helpful sarnold, very helpful :-P
[14:41]  * sarnold bows
[14:41] <cpaelzer> anyway I'll have a look
[14:42] <didrocks> thx cpaelzer
[14:42] <cpaelzer> #topic Incomplete bugs / questions
[14:42] <cpaelzer> Mission: Identify required actions and spread the load among the teams
[14:42] <cpaelzer> #link https://bugs.launchpad.net/ubuntu/?field.searchtext=&orderby=-date_last_updated&field.status%3Alist=INCOMPLETE_WITH_RESPONSE&field.status%3Alist=INCOMPLETE_WITHOUT_RESPONSE&field.subscriber=ubuntu-mir
[14:42] <cpaelzer> gsasl just landed 2.x
[14:42] <cpaelzer> that is the update there
[14:42] <didrocks> (btw, sorry for missing the parsing part)
[14:42] <cpaelzer> np didrocks, we come to that later
[14:43] <didrocks> I asked jawn-smith to have a look at the diff, not redo a whole MIR
[14:43] <cpaelzer> there is always a lessons learned :-)
[14:43] <cpaelzer> libiso* is also ok
[14:43] <cpaelzer> was reviewed waits for the reporting team
[14:43] <cpaelzer> I think we can go on
[14:43] <jawn-smith> ack, will hopefully have that done today
[14:43] <cpaelzer> thanks jawn-smith
[14:43] <cpaelzer> #topic MIR related Security Review Queue
[14:43] <cpaelzer> Mission: Check on progress, do deadlines seem doable?
[14:43] <cpaelzer> #link https://bugs.launchpad.net/~ubuntu-security/+bugs?field.searchtext=%5BMIR%5D&assignee_option=choose&field.assignee=ubuntu-security&field.bug_reporter=&field.bug_commenter=&field.subscriber=ubuntu-mir
[14:43] <cpaelzer> Internal link
[14:43] <cpaelzer> - ensure your teams items are prioritized among each other as you'd expect
[14:43] <cpaelzer> - ensure community requests do not get stomped by teams calling for favors too much
[14:43] <cpaelzer> #link https://warthogs.atlassian.net/jira/software/c/projects/SEC/boards/594
[14:43] <cpaelzer> sarnold: I keep saying the list grows - but it really really does by now
[14:44] <cpaelzer> you said "telegraf and something else in progress" often enough (no offense) - who do we need to bully to give you more time and people?
[14:44] <sarnold> aye, and I don't expect any progress on it this week, the security team is sprinting this week
[14:44] <cpaelzer> sarnold: can the outcome of the sprint be that this gets more attention before we have the same explosion as last cycle?
[14:45] <sarnold> cpaelzer: I believe we do have a short meeting on MIRs to make sure we're all on the same page, yeah
[14:45] <cpaelzer> ok, please push as hard as you can on it sarnold. Because we will ask you every week
[14:45] <sarnold> I expect nothing less :D
[14:45] <cpaelzer> and we includes more or less everyone requesting those cases
[14:46] <cpaelzer> which ends up to be a lot of people :-)
[14:46] <cpaelzer> #topic Any other business?
[14:46] <sarnold> none here
[14:46] <cpaelzer> her ewe come to the case you mentioned didrocks
[14:46] <slyon> Just a FYI that I rejected this from last week: https://bugs.launchpad.net/ubuntu/+source/python-charset-normalizer/+bug/1977475
[14:46] <cpaelzer> thanks slyon - we (the reporting team) agreed
[14:46] <slyon> I don't think it's strictly needed and would introduce duplication. ACKed by Lena
[14:46] <cpaelzer> we found the switch to the normalizer, but not the debate to drop it alltogether
[14:46] <cpaelzer> that really helped - thanks slyon
[14:47] <slyon> nothing else from my side
[14:47] <cpaelzer> on gsasl didrocks and I had a talk
[14:47] <cpaelzer> it was first marked as not needing a security review
[14:47] <joalif> nothing here I still work on the ipmitool review
[14:47] <cpaelzer> and I want to point us all to the rules section [Security] for a quick check
[14:47] <cpaelzer> thanks joalif
[14:48] <cpaelzer> it currently says
[14:48] <cpaelzer> TODO: - history of CVEs does not look concerning
[14:48] <cpaelzer> TODO: - does not run a daemon as root
[14:48] <cpaelzer> TODO: - does not use webkit1,2
[14:48] <cpaelzer> TODO: - does not use lib*v8 directly
[14:48] <cpaelzer> TODO: - does not parse data formats
[14:48] <cpaelzer> TODO: - does not open a port/socket
[14:48] <cpaelzer> TODO: - does not process arbitrary web content
[14:48] <cpaelzer> TODO: - does not use centralized online accounts
[14:48] <cpaelzer> TODO: - does not integrate arbitrary javascript into the desktop
[14:48] <cpaelzer> TODO: - does not deal with system authentication (eg, pam), etc)
[14:48] <cpaelzer> TODO: - does not deal with security attestation (secure boot, tpm, signatures)
[14:48] <cpaelzer> That covers a lot, but we have (didrocks now, but I myself in other cases in the past) to make a good split on when it is "parse data"
[14:48] <cpaelzer> I mean is having any CLI or socket or API or I/O => "parsing data"
[14:48] <sarnold> it's hard to say, since that's the core behaviour of nearly everything..
[14:48] <cpaelzer> I do not want to get philosphical, but
[14:49] <cpaelzer> I'd propose to add one more line to catch one particular kind that obviously needs to go through security expertise
[14:49] <cpaelzer> TODO: - does not deal with cryptography (en-/decryption, certificates, signing, ...)
[14:49] <slyon> yeah, I've been strugling with that one, too
[14:49] <sarnold> i've always interpreted it to mean more along the lines of images, video, audio, xml, json, asn.1 ..
[14:49] <didrocks> I was going to propose about dealing with certificates
[14:49] <didrocks> I guess your line captures it
[14:50] <sarnold> I like the cryptography addition, yeah
[14:50] <cpaelzer> could I get an discussion7ack on that line above then we could talk about potential second rule that makes the "parsing" more granular
[14:50] <didrocks> sounds like a good addition to me
[14:50] <cpaelzer> opinions, objections, +1 on the line proposed above
[14:50] <didrocks> +1
[14:50] <slyon> +1
[14:50] <joalif> +1
[14:50] <sarnold> +1
[14:50] <slyon> also +1 on sarnold's suggestion about the parsing part
[14:51] <cpaelzer> there I have come up with something
[14:51] <cpaelzer> TODO: - does not parse data formats (from files [images, video, audio, xml, json, asn.1], network packets, structures, ...)
[14:51] <cpaelzer> are there other commonly epxloitet attack vectors worth to be mentioned explicitly as example?
[14:52] <didrocks> I wonder about json/yaml, because let’s say any package that embeds a json parser would be impacted, no?
[14:52] <didrocks> (let’s say, a go app vendoring go-yaml )
[14:53] <didrocks> so basically, everything having configuration would end up in the security queue, is that desired?
[14:53] <sarnold> it really does run the risk of sending *everything* through the security team..
[14:53] <didrocks> which would be the safest option. Then we have to deal with reality…
[14:53] <sarnold> some additional 'from untrusted sources' might be nice, but that can be hard to tell
[14:54] <didrocks> even libreoffice, in some way, is parsing its own file format
[14:54] <sarnold> and ossfuzz finds things with libreoffice basically every other day..
[14:54] <cpaelzer> untrusted source is good here
[14:54] <didrocks> yeah, I like the untrusted source as a delimiter
[14:54] <cpaelzer> indeed
[14:55] <cpaelzer> TODO: - does not parse data formats (files [images, video, audio, xml, json, asn.1], network packets, structures, ...) from an untrusted source
[14:55] <cpaelzer> could we vote on that as well please then?
[14:55] <cpaelzer> +1
[14:55] <didrocks> +1
[14:55] <sarnold> I think mostly the 'this needs security review' vs 'this doesn't need security review' mostly works out pretty well, so in some sense I think the intuitons of the team have been pretty good
[14:55] <slyon> yes. and the sysadming (e.g. config files yaml/json/xml/ini) would be trusted
[14:55] <slyon> +1
[14:55] <joalif> +1
[14:55] <sarnold> +1
[14:56] <cpaelzer> ok thank you all
[14:56] <cpaelzer> consider both rules added (in a bit)
[14:56] <slyon> thank you cpaelzer!
[14:56] <didrocks> thank you cpaelzer for the proposals :)
[14:57] <cpaelzer> we can only get better if we try :-)
[14:57] <cpaelzer> anything else to discuss left?
[14:57] <didrocks> nothing from me this week
[14:57] <joalif> nothing from me
[14:57] <slyon> nothing here
[14:58] <cpaelzer> ok, clsoing then
[14:58] <cpaelzer> or rather "closing"
[14:58] <cpaelzer> FYI: review rules in the wiki updated
[14:58] <didrocks> (parsing error)
[14:58] <cpaelzer> #endmeeting
[14:58] <meetingology> Meeting ended at 14:58:25 UTC.  Minutes at https://ubottu.com/meetingology/logs/ubuntu-meeting/2022/ubuntu-meeting.2022-06-21-14.34.moin.txt
[14:58] <didrocks> thanks!
[14:58] <sarnold> thanks cpaelzer, all :)
[14:58] <joalif> thanks cpaelzer, all:)
[14:59] <slyon> thank you!
[19:01] <rbasak> o/
[19:03] <rbasak> vorlon: meeting?
[19:03] <rbasak> I don't see the other two here.
[19:19] <rbasak> vorlon: also, when you see this, please could you update the calendar meeting to the new phasing? I can't do that as I don't have edit rights; I think you "own" the event.
[19:19] <rbasak> Perhaps that's why you're not here :)
[19:20] <vorlon> hi, sorry! that's exactly right, didn't realize that's why the calendar wasn't updated
[19:20] <vorlon> and didn't realize the meeting was on until I got email notifications of your google doc edits
[19:21] <vorlon> updated now, for all that's worth :/
[19:21] <rbasak> Thanks :)
[19:21] <rbasak> I used the time to work on the doc
[19:21] <vorlon> ack
[19:22] <vorlon> regarding that, are we close to a conclusion?  I wasn't sure how much sil2100 had reviewed the current doc
[19:22] <vorlon> (I'm unsurprised if he's unavailable right now fwiw, there was an... injury earlier today while he was at the vet)
[19:24] <rbasak> It's on me at the moment.
[19:24] <rbasak> I have to work out what we're already shipping and what exceptions might be needed.
[19:25] <rbasak> That's the biggest task I think.
[19:26] <vorlon> ok


[08:24] <maxb> Booting intrepid-proposed's kernel, I get the boot hanging at: udevd-event[2606]: run_program: '/sbin/modprobe' abnormal exit
[08:25] <maxb> Can anyone point me at any relevant debugging options that might help deterimine why?
[08:25] <maxb> thanks
[08:32] <anubhav> you can boot the kernel with "debug" parameter.That will provide you with more info.You can use grub to add parameter to the kernel command line
[08:35] <smb_tp> I wonder whether changing udev debugging level in the conf and recreating the initrd for the new kernel from an older one also brings more ingo. Sounds like some module could not get loaded and after it hangs maybe an important one. Also removing quiet from the grub line might be a good idea
[08:38] <maxb> smb_tp: sounds good, /etc/udev/udev.conf, udev_log="debug" ?
[08:40] <smb_tp> maxb, That can give a lot of output. If that is too much maybe "info". Maybe going from the kernel options via info to debug...
[08:40] <maxb> On an unrelated note, having tagged an lbm bug regression-proposed, is there anything else I should be doing also?
[08:41] <smb_tp> Can you quickly point to it? Then I have a look
[08:42] <maxb> bug 337929
[08:42] <ubot3> Malone bug 337929 in linux-backports-modules-2.6.28 "ieee80211_regdom=EU now causes oops after latest update" [Undecided,New] https://launchpad.net/bugs/337929
[08:45] <maxb> eek, yeah that's a lot of udev spew. /me tries info
[08:46] <smb_tp> maxb, The bug seems to be complete afaics. If there are questions we surely will ask
[08:47] <maxb> ok, just checking I wasn't supposed to report potential regressions in proposed anywhere special
[08:49] <smb_tp> Just in the sense of "we have to get this fixed before it moves to updates". It might pop up on certain screens to have a look at
[08:50] <maxb> oh, guh
[08:50] <maxb> my modprobe error was the ath5k BUG-ing :-)
[08:51] <smb_tp> eh, so likely related to the bug
[08:57] <apw> smb_tp, thats odd ... i would expect ieeee80211_regdome to simply cause the module to fail to load ... we have a bug on that too
[08:58] <smb_tp> I would be thinking that if the module causes an oops, then strange things can happen to the modprobe as well...
[08:58] <apw> modprobe may well hang for ever, and no more modprobes be possible
[08:58] <smb_tp> and that is what seems to happen
[09:01] <apw> it sounds a lot like the kernel and lbm there are out of sync in terms of the config options for REGULATORY domain
[09:02] <apw> the variable that those ieee80211_regdom= things point to is no longer there in our latest kernels
[09:02] <apw> as we have CRDA enabled instead
[09:02] <smb_tp> It could be. Though for intrepid this should behave the old way (and certainly not oops)
[09:03] <apw> yeah it should.  but just check it not the same package
[09:04] <smb_tp> yeah. I thought both were updated to the same compat-wireless master ...
[09:04] <smb_tp> but i have to check
[09:05] <smb_tp> I see. Intrepid should be at 2009-03-04, Jaunty at 2009-03-17
[09:06] <smb_tp> maxb, the dmesg on the bug is for Jaunty it seems. Could you add one for Intrepid as well?
[09:09] <maxb> sure
[09:10] <maxb> err
[09:11] <maxb> On intrepid the failure mode somehow manages to be different such that it doesn't end up in /var/log/ there :-/
[09:11] <maxb> this may be a bit more difficult
[09:14] <maxb> here I go rebooting, let's try it again
[10:12] <Keybuk> amitk: your change is good
[10:12] <Keybuk> I think I asked Ben to do that years ago
[10:12] <Keybuk> but he bitched :p
[10:12] <Keybuk> it means I can eliminate a tiny bit of the udev init script as well
[10:13] <amitk> Keybuk: I tripped across it while going over the entire config for the babbage
[10:13] <amitk> Keybuk: though I don't this the actual impact is measurable
[10:13] <Keybuk> it's just nicer
[10:13] <amitk> s/this/the
[10:14] <amitk> yes
[10:14] <amitk> Keybuk: could you please ack it then?
[10:14] <Keybuk> amitk: I've replied with a Signed-off-by line of my own
[10:14] <amitk> thanks
[10:59] <cking> Any idea why CONFIG_RTC_DRV_CMOS is disabled for Hardy and enabled for Intrepid + Jaunty? It appears to been disabled in linux-source-2.6.22 (2.6.22-6.13) gutsy
[11:04] <cking> ..perhaps I need a time machine to figure out the rationale behind the decision
[11:13] <cking> smb_tp: ^^ wrt CONFIG_RTC_DRV_CMOS in Hardy?
[11:21] <apw> cking, ok can you tell me what might trigger the grub error: Error 13: Invalid or unsupported executable format
[11:21] <cking> have you moved from ext3 to ext4?
[11:22] <apw> yes, but not recently
[11:22] <apw> do i need to reinstall grub or something?
[11:22] <apw> though i can boot an older kernel
[11:23] <cking> When in the boot process is it occuring? Any other messages?
[11:23] <apw> very first thing after it says its booting an image
[11:23] <apw> as if the actual binary was corrupt
[11:23] <cking> OK - sounds like the kernel image is corrupt
[11:23] <cking> especially if you can boot older kernels
[11:24] <apw> and yet the md5sum is the same on my boxes
[11:24] <apw> and the other is booted from it
[11:24] <apw> apw@chloe:/boot$ md5sum vmlinuz-2.6.28-11-generic
[11:24] <apw> 6dfd6e870419d93a37c27341940316e7  vmlinuz-2.6.28-11-generic
[11:24] <apw> apw@lana:/boot$ md5sum vmlinuz-2.6.28-11-generic
[11:24] <apw> 6dfd6e870419d93a37c27341940316e7  vmlinuz-2.6.28-11-generic
[11:24] <apw> apw@lana:/boot$ cat /proc/version
[11:24] <apw> Linux version 2.6.28-11-generic (buildd@yellow) (gcc version 4.3.3 (Ubuntu 4.3.3-5ubuntu4) ) #35-Ubuntu SMP Wed Mar 18 21:55:34 UTC 2009
[11:25] <cking> grub has a block map command  that allows one to get a block map of the image. It may be worth checking grubs idea of the block map for this file compared to the reality
[11:25] <apw> ok how do i get that in OS and grub
[11:26] <cking> this is the fun bit. In Linux there is a ioctl() FIBMAP or something like that to get a block map of a file... hold on..
[11:27] <cking> I will Email you the source to my fibmap dumper tool
[11:27] <apw> nice
[11:29] <apw> cking, ohhh blocklist in grub is unhappy
[11:30] <apw> Error 24: Attempt to access block outside partition!
[11:30] <cking> owch
[11:30] <cking> ext4?
[11:30] <apw> yes sir
[11:30] <apw> its even printing extents :)
[11:30] <apw> i assume thats <nnnn>+8 means
[11:31] <cking> This is good and bad. Good that we have somebody who can send me an image I can work on :-) bad that it's screwed
[11:31] <cking> Can you dd up the boot partition so I can look at it?
[11:33] <apw> its my entire disk :(
[11:34] <apw> (hd0,0)1546320+8.32+8,4096+8,402255872+8,4096+8,2792+8,402280448+4
[11:34] <apw> that looks utterly corrupted to me
[11:34] <cking> urgghh.
[11:34] <apw> if its an extent list, it has the same extent twice doesn't it?
[11:35] <cking> not sure
[11:35] <cking> where's ted?
[11:35] <apw> i think i'll boot a recovery cd and fsck it before i do anything else
[11:35] <smb_tp> apw, could it be it got a wrong kernel, like a 64bit on a 32bit machine or somethin?
[11:35] <apw> don't think so, it should boot the kernel then and fail at userspace
[11:35] <cking> I'd dd the image to backup then fsck it
[11:35] <smb_tp> cking, wrt to the config option: so it has been disabled before intrepid and enabled starting with it and later?
[11:35] <apw> cking, no point in backing it up
[11:36] <apw> its all recoverable from the other machine
[11:36] <cking> Ah. fsck will be fast, that's for sure
[11:36] <apw> its had early ext4 on it so it could be corrupt
[11:36] <cking> smb_tp: it appears to be disabled pre-hardy and re-enabled post hardy.
[11:36] <apw> from there, so its probabally not pejorative of the current kernel even if its broken
[11:37] <cking> apw: I agree
[11:37] <smb_tp> apw, eek, should have read the whole backlog then
[11:37] <cking> smb_tp, lemme see..  You're living dangerously
[11:38] <apw> heh, you promised me it was working :)
[11:38] <cking> ..yeah, but I did not promise it was 100% reliable :-)
[11:38] <cking> ..what's it on?
[11:39] <apw> its an intel shv
[11:39] <cking> shv? eh?
[11:40] <apw> its a intel quad core thing
[11:40] <cking> owch.
[11:40] <apw> well it was, its a heap at the mo :)
[11:40] <cking> and it went wrong on the reboot?
[11:40] <apw> nice our rescue disk doen't have fsck on it
[11:40] <apw> well ... it fails to boot from the new kernel
[11:40] <apw> i suspect the upgrade broke it
[11:40] <apw> as in doing the upgrade
[11:42] <smb_tp> apw, I think fdisk in the rescue disk might be a good proposal
[11:43] <cking> smb_tp: hardy debian/changelog: linux-source-2.6.22 (2.6.22-6.13) gutsy; urgency=low ... build/config: Disable CONFIG_RTC_DRV_CMOS
[11:43] <apw> nope not one of those either
[11:43] <apw> this alternate disk is USELESS
[11:43] <cking> ..remove disk and fsck on another box?
[11:43] <smb_tp> apw, would a live cd work?
[11:44] <apw> trying now
[11:45] <smb_tp> cking, I have to look into that a bit. Reasons do not come to my mind immediatly
[11:45] <apw> cking, i am a s/w engineeer
[11:45] <cking> heh
[11:45] <apw> i expect to be able to fix this from outside the box!
[11:46] <apw> though i have screwdrivers on standby
[11:46] <cking> surely using a screwdriver is software engineering?
[11:46] <apw> heh, only h/w engineering when you need a hammer?
[11:47] <cking> or solder
[11:48] <apw> fsck says 'clean', is there a 'look do it properly' option?
[11:48] <smb_tp> -f
[11:49] <apw> taking more time at leas
[11:49] <apw> cking, so how is fsck fast in ext4?  waht do they do different?
[11:50] <smb_tp> iirc they can mark regions they have not touched, so those can be skipped
[11:50] <cking> apw: http://thunk.org/tytso/blog/2009/02/26/fast-ext4-fsck-times-revisited/
[11:51] <cking> faster "due to the elimination of indirect blocks and the uninit_bg feature reducing the amount of disk reads necessary in e2fsck’s pass 1"
[11:51] <cking> so now you know :-)
[11:52] <apw> ok so its fsck'd ok
[11:52] <apw> and thinking about it the md5sum of the file was fine too
[11:52] <cking> fingers crossed
[11:52] <apw> so i am suspect fo grub
[11:53] <cking> How big was /boot?
[11:53] <cking> ..oh yeah. the whole disk for / wasn't it?
[11:55] <apw> yep massive
[11:56] <cking> Can you run the fibmap prog and workout which blocks are used by the kernel image. Maybe we can dd up just some of this disk image to see why grub is bawking
[11:56] <apw> 306M blocks
[11:57] <cking> bit to big to fit on a DVD then :-(
[11:58] <apw> heh yeah
[11:59] <cking> I will compare and contrast the grub 0.97 + ext4 support with grub 2 and see if anything make sense
[12:01] <cking> apw: I wonder if one could create an USB bootable drive and install grub 2 on this and see if this can read the kernel off the hard disk.
[12:02] <cking> ..me goes to try this
[12:02] <apw> cking, i guess its possible, i'd have no idea how
[12:02] <apw> cking, the blocklist from fibmap bears no relation to that from grub
[12:02] <apw> i'd susgest its overflowwing
[12:03] <cking> mmm.. could be. How about comparing older kernels to see if grub vs fibmap marry up just for a sanity check
[12:05] <apw> the working kernel seems pretty similar in location
[12:06] <cking> and no major weirdness in the fibmap wrt sequential blocks etc
[12:06] <apw> it looks like its in two extents to me
[12:06] <apw> assuming there is no limits on actual extents
[12:06] <rtg> amitk: I guess you noticed the ARM kernel didn't build? I think the Kconfig for drivers/cpufreq has problems, but it looks like you must build in the performance governor.
[12:07] <amitk> rtg: it doesn't like the cpufreq driver built as a module
[12:08] <rtg> amitk: right, I found that out last night, but when I quickly looked at your last push, I thought you had done the same
[12:08] <amitk> rtg: and regarding hitting your shitlist looks like you didn't get my last message
[12:08] <amitk> 21:34 < amitk> rtg: had to force push to jaunty. Found a typo in my patch (im51 -> imx51)
[12:08] <cking> apw: can you send me the fibmap of a good kernel and the badone
[12:08] <amitk> rtg: so I deserved it :-/
[12:09] <rtg> amitk: hmm, sure didn't. I get so many flashes from this IRC client some days that I miss things.
[12:10] <apw> cking, sure ...
[12:10] <amitk> rtg: I've got the build issues fixed. Just testing with ogra regarding AA and aufs issues. Then I'll fix d-i for imx51
[12:11] <rtg> amitk: ok
[12:11] <cking> I'm looking at making a bootable USB image with grub2..
[12:15] <apw> cking, on its way
[12:15] <apw> i blocklisted a good kernel and its two extents
[12:15] <cking> apw, that's good. thanks
[12:16] <apw> i can keep this pretty much indefinatly if its a help
[12:20] <apw> cking, i note that grub is reporting block number *8 the fibmap
[12:20] <apw> but they are pretty similar
[12:20] <apw> 402243640
[12:20] <apw> 17F9C038
[12:20] <apw> 50281984*8
[12:20] <apw> 17F9F000
[12:20] <apw> first is the one which works
[12:21] <cking> apw: one could inform grub of the block map (from the map from fibmap) by hand and see if this boots - http://www.gnu.org/software/grub/manual/grub.html#Block-list-syntax
[12:22] <apw> hmmm
[12:22] <cking> bit of a pain I know
[12:31] <Kano> hi, is there a karmic repo already? as you need new squashfs-tools from cvs
[12:32] <Kano> squashfs 4.0 from 2.6.29 is not compatible with old squashfs 3
[12:33] <apw> Kano, repo as in the full archive?
[12:33] <apw> there is no karmic archive yet, and won't be till jaunty is released
[12:34] <apw> cking, ok i have converted the fib lists, and get the same as grub for the X8
[12:34] <apw> booting the X11 block lists gives Error 24: Attempt to access blocj outside partition
[12:34] <apw> also do you have any clue as to what this format even means?
[12:35] <apw> (hd0,0)1546320+8.32+8,4096+8,402255872+8,4096+8,2792+8,402280448+4
[12:35] <apw> note the first bit has two +'s
[12:35] <apw> it should look like: 402255872+4096,402280448,2792
[12:35] <apw> it should look like: 402255872+4096,402280448+2792
[12:36] <apw> the grub manual you pointed me to doesn't even mention two +'s as an option: 1546320+8.32+8
[12:37] <apw> oh perhaps that was me ...
[12:38] <apw> bah it was, i forgot i hand transcribed it
[12:40] <Kano> well you can not use new squashfs-tools with jaunty when you don't update squashfs to 4.0
[12:40] <Kano> would be basically no problem however
[12:41] <Kano> as you have to do that for karmic too
[12:44] <cking> apw, it's baffling. I need to look at the source
[12:45] <apw> Kano, ok so there is a userspace kernel depenancy there
[12:45] <apw> which will be sorted out in karmic when it opens
[12:46] <Kano> i sent the aufs compile fix to the list, i booted it already live *g*
[12:46] <apw> yep saw that, thanks for the patch, i am sure it'll be showing up soon enough in our tree
[12:47] <apw> cking, yeah is most perplexing for sure
[12:47] <cking> apw, especially the 8.32 part
[12:47] <Kano> i looked at zen sources but only fixed the compile issues. maybe a new aufs snapshot would be good too
[12:47] <apw> cking, i note that there is a 4096 in there which is the _size_ i am expecting
[12:48] <apw> its almost as if its using smaller sizes for the extents on that one
[12:48] <apw> ie less bits for the pointers
[13:24] <cking> apw, did you try booting specifying the kernel with the block list of  402255872+4096,402280448+2792?
[13:30] <apw> yeah
[13:31] <apw> cking, yeah that produced the block out of partition error
[13:31] <cking> OK - lemme build grub2 with some debug in the ext fs handler.
[13:31] <apw> what will you send me, usb image to boot?
[13:32] <cking> ..yep - working on this. It's a little tangled but doable
[13:32] <apw> something to have on a stick me thinks
[13:33] <cking> indeed
[13:35] <apw> rtg, under intrepid a fair number of people are going to have ended up with the ieee80211_regdom=FOO thing set in their module options, when they upgrade to Jaunty those will be preserved and prevent the module loading
[13:36] <apw> is there a something we can do to remove them, or perhaps we could make those options valid but ignored in jaunty
[13:36] <rtg> apw: so, the module won't load because that is no longer a valid option?
[13:36] <apw> yeah as its not a valid option we lose the module completely
[13:37] <rtg> apw: we should certainly release note it.
[13:37] <apw> IntuitiveNipple has reported it on Jaunty upgrades which we could probabally ignore as they are all knowledgable people, but those on Intrepid are likley to be less aware
[13:37] <apw> ahh good point.  should have thought of that
[13:39] <rtg> apw: my thinking is that this is something outside of our normal install, so anyone who does something like that, e.g., adds a module option, is also gonna have to be smart enough to figure out the borkage on an upgrade.
[13:40] <apw> thats also a fair point.  they know they put it in
[13:40] <smb_tp> apw, Did you have time to check whether the option always causes an oops or just a load fail as expected
[13:40] <rtg> besides, its not like the wireless subsystem hasn't already had some turbulence
[13:41] <apw> not tried that yet.  will do so once i am upgraded on here
[13:41] <apw> which i would have done, if my build box wasn't in a heap over ext4
[13:41] <rtg> smb_tp: an oops is a bit more serious
[13:41] <smb_tp> bug 337929
[13:41] <ubot3> Malone bug 337929 in linux-backports-modules-2.6.28 "ieee80211_regdom=EU now causes oops after latest update" [Undecided,New] https://launchpad.net/bugs/337929
[13:41] <smb_tp> I just had not time to look furhter into that
[13:42] <smb_tp> Was reported to happen for intrepid after the latest maste 2009-03-03(?) update as well
[13:43] <rtg> smb_tp: I'm not to keen on the VIA sata patch for Hardy. what do you think?
[13:44] <smb_tp> rtg, not in that form anyways. too much thrown into a single patch
[13:44] <smb_tp> and I don't like the two libata changes
[13:44] <smb_tp> I fail to understand what they are about
[13:45] <rtg> smb_tp: my thoughts exactly. this falls under the heading of new hardware enablement, so I'm inclined to reject it for Hardy.
[13:45] <smb_tp> I wanted to give them a chance to come with better patches. I'll write something up later
[13:46] <rtg> amitk: I've rebuilt ARM with the correct CPU freq settings. shall I push or have you already commited to your local repo?
[13:46] <amitk> rtg: I have it my local repo along with some other changes
[13:47] <rtg> amitk: ok. you should push at least that fix so the repo builds ARM
[13:48] <rtg> amitk: that and the /sbin/hotplug fix as well
[13:49] <amitk> rtg: I need to make sure imx51 works well since I might not get another upload before beta.
[13:51] <rtg> amitk: it would sure be nice if what is committed to the core repo actually builds.
[13:51] <rtg> if you aren't comfortable with the CPU freq commit, then revert it.
[13:52] <amitk> rtg: naaah. the cpufreq part is fixed. I want to make sure the AA/aufs parts have the correct settings. ogra's testing them out right now.
[13:53] <rtg> smb_tp: you gonna teach ikepanhc how to use 'git request-pull' next ? (seeing as how you are his mentor)
[13:54] <smb_tp> rtg, We started this morning send-mail for the acks and later request-pull for the patch
[13:54] <ikepanhc> rtg: I miss something in the patch?
[13:55] <rtg> ikepanhc: I haven't checked it yet, but I was just wondering where smb_tp was headed with your continuing education. (perhaps I'm just annoying him as well)
[13:56] <smb_tp> rtg, You mean as in "will do" or "am already doing" ;-)
[13:57] <rtg> smb_tp: annoying you? I assume I'm doing that already.
[13:57] <smb_tp> rtg, Not too much :)
[13:57] <ikepanhc> oh, I ask some this morning. but I am not fully understand the output of git-request-pull
[13:58] <smb_tp> rtg, Really apw an me spoke with ikepanhc this morning and agreed that for review the git-send-email is good and later if you ack it for Jaunty he will post the request-pull for you
[13:59] <smb_tp> ikepanhc, Ok, how may we help?
[14:00] <mdz> I get two kerneloops popups on every resume
[14:00] <mdz> I think this is due to https://bugs.edge.launchpad.net/ubuntu/+source/kerneloops/+bug/330606
[14:00] <ubot3> Malone bug 330606 in kerneloops "WARNING: synaptics was reset on resume, see synaptics_resume_reset if you have trouble on resume" [Undecided,New]
[14:00] <mdz> i.e. WARNING: synaptics was reset on resume, see synaptics_resume_reset if you have trouble on resume  [edit]
[14:00] <mdz> [It's All Text!] [It's All Text!] [It's All Text!] [It's All Text!] [It's All Text!] [It's All Text!] [It's All Text!] [It's All Text!] [It's All Text!] [It's All Text!] [It's All Text!] [It's All Text!] [It's All Text!] [It's All Text!] [It's All Text!] [It's All Text!] [It's All Text!] [It's All Text!] [It's All Text!] [It's All Text!] [It's All Text!] [It's All Text!] [It's All Text!] [It's All Text!] [It's All Text!]
[14:00] <mdz> [It's All Text!] [It's All Text!] [It's All Text!] [It's All Text!] [It's All Text!] [It's All Text!] [It's All Text!] [It's All Text!] [It's All Text!] [It's All Text!] [It's All Text!] [It's All Text!] [It's All Text!] [It's All Text!] [It's All Text!] [It's All Text!] [It's All Text!] [It's All Text!] [It's All Text!] [It's All Text!] [It's All Text!] [It's All Text!] OkCancel
[14:00] <mdz> eek
[14:00] <mdz> I meant: WARNING: synaptics was reset on resume, see synaptics_resume_reset if you have trouble on resume
[14:00] <ikepanhc> smb_tp: Let me take a look at the output again
[14:00] <mdz> I think WARNING: triggers kerneloops
[14:01] <rtg> mdz: apw suspected that in an email to me yesterday
[14:01] <rtg> because the resume is too slow
[14:01] <mdz> this one's killer because it happens twice on every single resume
[14:01] <apw> hrmmm.  i had not considered it might trigger that.
[14:02] <rtg> apw: I'm don't think a WARNIG should trigger the oops scavenger
[14:02] <apw> that fix has not hit upstream and they implemented it slightly differently
[14:02] <rtg> apw: what fix is that?
[14:02] <apw> that really shouldn't imho, but i will look at the upstream version of the patch
[14:03] <apw> rtg the fix which this warning is part of
[14:03] <apw> they took it and accepted it, but then mushed it a bit later in the process
[14:03] <apw> and the warning was removed i think
[14:04] <apw> mdz i will pick that up and see what is what
[14:04] <rtg> apw: ok, I guess we need to pull that in, 'cause its gonna annoy a lot of folks otherwise.
[14:04] <apw> yeah for sure.  i suspect we need to check if kernel oops is being overly strong as well
[14:05] <Keybuk> rtg: I don't suppose the hotplug change could sneak in with the next kernel upload?
[14:05] <rtg> Keybuk: _if_ you can get amitk to push his changes, I'd be happy to accept it.
[14:06] <amitk> rtg: do you have a train to catch?
[14:06] <amitk> :)
[14:06] <rtg> amitk: this is my day to annoy _everyone_
[14:07] <amitk> I'll push it with the babbage changes
[14:08] <mdz> apw: thanks
[14:09] <ikepanhc> smb_tp: I use the command to show the summary of change: "git-request-pull origin/HEAD ."
[14:09] <ikepanhc> Is that right?
[14:09] <smb_tp> ikepanhc, not quite. there should be your remote repository somewhere...
[14:11] <ikepanhc> you mean the url? give it git://kernel.ubuntu.com/ubuntu/ubuntu-jaunty.git?
[14:11] <rtg> ikepanhc: something like this: 'git request-pull <SHA1> git://kernel.ubuntu.com/rtg/ubuntu-jaunty'
[14:12] <ikepanhc> point to your git tree, so that you will know the summary between our tree?
[14:16] <smb_tp> ikepanhc, the <sha> is the id of what was the head before you added something
[14:18] <rtg> ikepanhc: hmm, I'll be more literal. Use 'git request-pull <SHA1> git://kernel.ubuntu.com/ikepanhc/ike-jaunty.git' where <sha1> is the commit ID that you want me to start pulling from. Its _usually_ HEAD after you've rebased.
[14:21] <ikepanhc> got it, it means the output will tell you where to pulling, and the summary of it
[14:21] <ikepanhc> am I right?
[14:21] <rtg> ikepanhc: correct
[14:21] <ikepanhc> let me take a try
[14:25] <smb_tp> rtg, with HEAD you probably mean origin/HEAD ...
[14:27] <rtg> smb_tp: perhaps, I've not used request-pull much myself because I'm typically the consumer. I thought the SHA1 was usually the commit ID of where you differences begin, e.g., the patches that you want pulled.
[14:27] <smb_tp> rtg, right. and imo origin/HEAD is what you pulled last and HEAD is your local head with your own changes
[14:28] <rtg> smb_tp: that makes perfect sense.
[14:29] <smb_tp> Plus it can be nicely automated with a wrapper script :)
[14:37] <ikepanhc> smb_tp: I got a warn: No branch of git://kernel.ubuntu.com/rtg/ubuntu-jaunty is at: 6afb87c: UBUNTU: SAUCE: Fixing symbol name in HECI module
[14:37] <smb_tp> ikepanhc, have you pushed to you repo before?
[14:38] <ikepanhc> smb_tp: not yet, I shall push to my repo at zinc first?
[14:38] <smb_tp> yes
[14:42] <ikepanhc> smb_tp: I have to go home now, its pretty late in Taiwan, otherwise no bus can take
[14:42] <smb_tp> ikepanhc, sure
[14:42] <smb_tp> off you go
[14:42] <ikepanhc> see you later
[14:46] <mdz> apw: yay, your script is in checkbox in jaunty now
[14:47] <apw> mdz yeah got it through in the end!
[14:47] <apw> and i've even tested it
[14:49] <mdz> apw: that'll save folks a step or two in testing
[14:49] <mdz> apw: will checkbox walk the user through the test as well soon?
[14:51] <rtg> amitk: forgot to mention that I did the newrelease thing, just copied the ARM ABI bits, etc.
[14:52] <amitk> rtg: ok, will git pull again to test
[14:59] <amitk> bradF: btw, I looked at your aufs changes to get it to compile w/o AA. They look sane to be, where sane = doing what has been done to all filesystems when AA patch was applied.
[14:59] <amitk> s/be/me
[15:01] <bradF> amitk: good, now I or someone needs to test them to see if they will actually work
[15:01] <rtg> bradF: where they is?
[15:02] <bradF> rtg: probably me, i'm working on getting things setup so that I can build a babbage image
[15:02] <rtg> bradF: 'they' being the AA patches.
[15:03] <bradF> rtg: I made the changes available to amitk in case he or one of the mobile guys wanted to give them a try before I got to it
[15:03] <rtg> bradF: there is a reason we have public git repos
[15:03] <bradF> rtg: and that is where my changes are
[15:05] <amitk> bradF: Compile-test and send the patch to kernel-team ML to see if someone recoils in horror looking at it.
[15:05] <amitk> then point them to what has been done to the other fs'es :)
[15:06] <bradF> amitk: it compiles
[15:06] <amitk> _then_ lets make sure it still works on booting with aufs
[15:07] <rtg> bradF: and so they are. I'm just a cranky bastard this morning.
[15:07] <bradF> amitk, rtg: will get the changes emailed out today
[15:08] <amitk> rtg: we know
[15:09] <bradF> rtg: I am sloooooow to learn sometimes, but I try :)
[15:11] <rtg> bradF: what is this? humor from mr stoicism? I'm just shocked.
[15:12] <bradF> rtg: you should deal with my business partners every day, it can be a bit trying
[15:38] <rtg> bradF: I suggest you get rid of the '#ifdef CONFIG_VSERVER' clauses altogether. That config option is totally meaningless as it does not exists anywhere but in that source file.
[15:39] <rtg> looks like hereditary forward porting cruft
[15:39] <bradF> rtg: right
[15:39] <rtg> bradF: it would simplify that patch a bit
[15:44] <amitk> rtg: so what happens if one of the modules (cbc in crypto) that is expected by d-i as a module is compiled-in. Does d-i complain?
[15:45] <rtg> amitk: yep, add a '?' so that its optional
[15:48] <rtg> amitk: the case where adding '?' isn't sufficient is when _all_ of the modules for that d-i are compiled into the kernel. Then you have to get more creative 'cause kernel-wedge bitches that the udeb will be empty.
[15:52] <amitk> rtg: that's where you exclude the udeb for that flavour?
[15:53] <rtg> amitk: the creative part? sometimes I just drop the whole udeb.
[16:03] <rtg> zul: what does the comment in this commit mean? http://kernel.ubuntu.com/git?p=chucks/ubuntu-ec2-jaunty.git;a=commit;h=c9e42c176084bfc18bede682332842a89d14c79d
[16:04] <kirkland> rtg: zul: xvd is what's used if the block device is virtio
[16:04] <rtg> the part about "This should not be included in the main ubuntu kernel." bothers me
[16:05] <kirkland> rtg: yeah, i agree
[16:06] <rtg> kirkland: and the patch changes the dev name to "sd", is that really what you want?
[16:07] <kirkland> rtg: i wouldn't think so
[16:07] <Ng> udev?
[16:07] <kirkland> rtg: if you're using virtio, you expect the device to be xvd*
[16:07] <kirkland> rtg: i have no context for what zul is trying to accomplish here
[16:07] <rtg> kirkland: looks like an ec2 instance
[16:07] <kirkland> rtg: i'm just interjecting that xvd* is sometimes used/expected
[16:08] <rtg> kirkland: zul's explanation on the k-t list was a bit terse (to put it mildly)
[16:09] <Ng> could a udev/rules.d file in some ec2 package (ec2-init?) not make appropriate symlinks?
[16:10] <rtg> Ng: possibly. I'm still trying to grok the impact of his patch set on the distro kernel.
[16:11] <Ng> (where "make appropriate symlinks" means "do any applicable udev magic up to and including renaming the devices". seems cleaner than a kernel patch, but I am probably lacking context)
[16:12] <rtg> Ng: if its a boot-essential device, then it will likely require some initramfs magic. can you do that with ec2 images?
[16:13] <Ng> you can with eucalyptus, but I've not used ec2 extensively enough to need to try
[16:23] <zul> rtg: looking
[16:24] <zul> rtg: basically ec2 uses an older version of xen which doesnt use virtio devices so if this patch is included in the main ubuntu kernel then it will break existing xen setups for jaunty
[16:24] <rtg> zul: is there any way to decide that dynamically?
[16:25] <zul> rtg: not that I know of, the ec2 kernel might have to be treated like a seperate tree like lpia
[16:25] <rtg_> oops
[16:25] <ivoks> sorry to interrupt, but i'm interested; is kernel aware of duplicate IPs on the same network?
[16:26] <rtg_> zul: ec2 might be a separate flavour. LPIA is an arch
[16:27] <zul> rtg_: maybe something like an ifdef for that case then?
[16:27] <rtg_> zul: lemme think about it.
[16:27] <zul> rtg_: k
[16:28] <rtg_> zul: other then that, this patch set is sufficient to create an ec2 capable xen client?
[16:28] <rtg_> it seems quite minimal
[16:28] <zul> rtg_: yep i was using it the other day and building images based on it right now
[16:29] <rtg_> cool
[16:29] <zul> better than the xensource patchset ;)
[16:30] <rtg> zul: what effect will some of these other config changes have on existing xen DomU clients?
[16:31] <rtg> CONFIG_XEN_BALLOON is dynamic mem allocation for the VM, right
[16:31] <rtg> ?
[16:31] <zul> yes
[16:31] <rtg> thats the one that might have an effect
[16:33] <zul> its something existing ubuntu xen users want for jaunty not for ec2 though
[16:35] <zul> the vmlinuz patch is very important though
[16:36] <rtg> zul: in that case, it deserves its own commit so we can track it against whatever LP bug is open on it.
[16:36] <zul> heh ill open a bug about it then :)
[16:37] <rtg> zul: the vmlinuz target appears to be the core of the patch set. How is it used? Does it get copied to the linux-image package?
[16:38] <zul> yes it does
[16:38] <rtg> so we end up with both bzImage as well as vmlinuz.
[16:38] <zul> the versions of xen that amazon is using doesnt understand the bzImage format more modern versions of xen does
[16:39] <rtg> how about existing implementations? will they continue to use bzimage?
[16:39] <zul> i think well the default in the rules.d/*.mk defaults to bzImage
[16:39] <zul> existing implementations do use bzimage
[16:41] <zul> rtg: if you require it https://bugs.edge.launchpad.net/ubuntu/+source/linux/+bug/345486
[16:41] <ubot3> Malone bug 345486 in linux "Please add ec2 support." [Undecided,New]
[16:41] <rtg> zul: if we made DEV_NAME in drivers/block/xen-blkfront.c a module or boot command line parameter, would you be able to launch an ec2 instance with that override?
[16:41] <zul> a module yes not a boot command line parameter
[16:42] <mdz> manjo: you're looking at kerneloops?
[16:42] <manjo> mdz, yes
[16:42] <mdz> manjo: I was just looking at it myself
[16:42] <mdz> here's a hint as to why it's not working
[16:42] <mdz> (gdb) print submit_pipe
[16:42] <mdz> $1 = 0x1c73360 "/usr/share/apport/kernel_oops\n"
[16:42] <rtg> zul: the other LP report I wanted was for XEN_BALOON
[16:42] <mdz> note the last character of the string
[16:43] <manjo> mdz, tying to get with kenvandine to get some testing info
[16:45] <manjo> mdz, do you have any notes/scribble from your testing ?
[16:45] <manjo> mdz, that might help me ?
[16:45] <mdz> manjo: ./kerneloops --nodaemon --file test/i386-bug-on.txt
[16:45] <mdz> manjo: did you see what I pasted above?
[16:45] <mdz> the config file parser is broken
[16:46] <manjo> mdz, ah yes ... you were few steps ahead of where I was
[16:49] <zul> rtg: https://bugs.edge.launchpad.net/ubuntu/+source/linux/+bug/345490
[16:49] <ubot3> Malone bug 345490 in linux "Please disable XEN_BALLOON and XEN_SAVE_RESUME for ec2" [Undecided,New]
[16:50] <rtg> zul: I thought XEN_BALLOON was important for non-ec2 instances also?
[16:51] <zul> it is, its not important for ec2
[16:51] <rtg> zul: well then, the bug subject seems a bit disingenuous
[16:52] <zul> disigenuous?
[16:53] <mdz> manjo: I have a patch
[16:53] <manjo> mdz, cool let me try it
[16:53] <manjo> mdz, lp# ?
[16:54] <mdz> manjo: bug 344813, attaching the patch now
[16:54] <ubot3> Malone bug 344813 in kerneloops "No apport report generated for kernel oops" [Medium,Triaged] https://launchpad.net/bugs/344813
[16:55] <mdz> manjo: patch is there now
[16:55] <mdz> seems to work OK with the patch, though it's a lot of dialogs
[16:56] <manjo> mdz, got it .. I am upgrading jaunty (almost done) and  I will apply/test and report back
[17:07] <amitk> rtg: changes for mx51 build tested and pushed
[17:08] <amitk> rtg: could you fire up you hoover for the entire arch?
[17:08] <rtg> amitk: yo 'da man
[17:08]  * amitk -> dinner
[17:16] <Blinkiz> rtg, Hi there. I have a question. This ext4 problem, zero-byte-file issue, do you think the patches for this will be back ported to jaunty when they are released? I have read something about it being fixed in 2.6.30.
[17:19] <rtg> Blinkiz: there are 3 patches currently in Jaunty that revert some ext4 behaviors to that of ext3. Ted has blogged about it extensively (as well as commented in Launchpad).
[17:33] <Blinkiz> rtg, Have tried to find this "ted", but I can't. Can you point me in the right direction?
[17:47] <rtg> amitk: your arm stuff built ok, as did the other arches
[17:47] <amitk> rtg: no d-i explosions?
[17:48] <rtg> amitk: debuild -b
[17:48]  * amitk seems to have finally grokked d-i
[17:48] <rtg> long live kernel-wedge
[18:09] <apw> kirkland, t
[18:09] <apw> this raid thing, its a software raid failure right
[18:10] <apw> what i really need to do is isolate the string of md style commands that are exectured thre
[18:10] <apw> to build the raid, then to build it again degraded
[18:10] <manjo> mdz, do u have a build env to build kerneloops ?
[18:13] <mdz> manjo: yes, don't you? ;-)
[18:13] <kirkland> apw: correct
[18:13] <kirkland> apw: that magic is in initramfs-tools package
[18:13] <mdz> manjo: I just built it on my jaunty system for test purposes
[18:14] <Ng> what would cause the kernel to refuse to rm a file on a local partition, with an error about a stale nfs handle?
[18:18] <Ng> weird, moved the file (it was a uuid thing in ~/.pulse/) out of the way so the gnome session could actually start and was then able to rm it
[18:26] <apw> kirkland, ok thanks
[18:27] <kirkland> apw: found it?  let me know if you need a specific pointer
[18:33] <apw> kirkland, so you are booting from one disk plain in the error case
[18:33] <IntuitiveNipple> Any ideas why with two identical notebooks with identical installations, both connecting to the same 802.11g AP, one would select region ZZE (Europe) and the other region ZZJ (Japan) ?
[18:34] <kirkland> apw: yeah
[18:35] <anubhav> different firmwares?
[18:35] <IntuitiveNipple> anubhav: Identical in every way
[18:36] <kirkland> apw: i could probably upload a kvm image that demonstrates the problem, if you like
[18:36] <kirkland> apw: might take a while, but would be ready by your tomorrow
[18:36] <apw> never tried to use kvm here, probabally take longer than debugging it
[18:37] <apw> where are the raid tools.  damn package names
[18:37] <IntuitiveNipple> mdadm
[18:39] <anubhav> IntuitiveNipple: cfg80211 selcts the region?
[18:40] <IntuitiveNipple> anubhav: That's correct, via the CRDA
[18:41] <anubhav> IntuitiveNipple: let me check the code,maybe there's some hint
[18:41] <IntuitiveNipple> anubhav: Don't worry about it, I'll get around to it eventually. I was just hoping someone may know off the top of their head
[18:42] <anubhav> :)
[18:52] <apw> kirkland, do you have a full dmesg of the failed boot available?
[18:54] <kirkland> apw: i don't
[18:55] <apw> is it possible to get?
[18:55] <apw> md says interesting things when its putting things together
[18:55] <kirkland> apw: hmm, not terribly easily
[18:55] <apw> if they fail etc
[18:55] <apw> there is no serial on qemu?
[18:55] <kirkland> apw: it'll be easiest if i just upload the disk image to p.u.c
[19:00] <apw> kirkland, where did this work before jaunty?
[19:01] <kirkland> apw: hardy, intrepid
[19:01] <kirkland> apw: and like a champ...  i tested it a thousand times during the intrepid cycle
[19:02] <apw> bah its huge numbers of commits either way to working
[19:03] <kirkland> apw: i can't tell you if this ever worked in jaunty
[19:03] <kirkland> apw: i don't remember it ever working
[19:03] <kirkland> apw: though, i worked on this almost full time in the intrepid cycle
[19:03] <kirkland> apw: and just happened to test it once in jaunty, realized that it regressed, and said wtf
[19:12] <apw> kirkland, one thing worth trying is trying to use the intrepid mdadm tools
[19:12] <apw> is that something you can test
[20:59] <dtchen> TheMuso: i think we ought to consider post-release SRU for http://kernel.ubuntu.com/git?p=dtchen/ubuntu-jaunty.git;a=commitdiff;h=fbcaa0c6f18b41482caa41ceb6b7875c7dbaaeef
[21:00] <TheMuso> dtchen: ok
[22:09] <Kano> rtg: http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-jaunty.git;a=commitdiff;h=85568da345d4348f33c69043c9bc4e78ad819706
[22:09] <Kano> rtg: you know that you need that for 2.6.29 too?
[22:10] <Kano> rtg: maybe 2.6.30 will have it
[22:11] <rtg> Kano: I am assuming 2.6.30 _will_ have it.
[22:11] <Kano> but not 2.6.29
[22:12] <rtg> nope, but I don't much care about 2.6.29. its a transitional version for Karmic
[22:12] <Kano> well i have got dkms updates for drm,but it would be nice if it would work out of the box
[22:13] <rtg> I expect those drm fixes will land early in the merge .30 merge window
[22:14] <Kano> maybe


[04:13] <Roguehorse> All quiet tonight ...
[04:17] <nhandler> At least in this channel :)
[04:18] <DonkeyHotei> all channels i'm in atm are quiet atm
[04:58] <Roguehorse> well, it's late too and a weeknight
[04:58] <Roguehorse> I have a friend from school coming over tomorrow wants me to teach him Linux
[04:59] <ianorlin> ah that sounds nice
[04:59] <Roguehorse> funny how people think it can be acieved in like, one sitting
[05:00] <Roguehorse> it will be, I have fun with that stuff
[05:00] <Roguehorse> s/acieved/achieved
[05:05] <Roguehorse> this is all contingent that he shows up =p
[05:06] <ianorlin> ah I know that fact
[05:09] <Roguehorse> oh yeah, we've all been there ... "sure, I'll wait around for you" (never show)
[05:09] <ianorlin> I heard it happens for people that rvsp for stuff online
[05:20] <Roguehorse> everyone gets it, no one is immune
[05:21] <Roguehorse> this is the first time he's ever come over so, I can't really say if he'll show or not
[05:34] <ianorlin> yeah first time going somewhere is most nerve wracking
[06:31] <Roguehorse> I should tell you guys about the 10 days I spent with a crazy woman in Florida I met on MySpace =)
[06:32] <ianorlin> Roguehorse: my mom is in mental hospital right now
[06:32] <Roguehorse> AH!
[06:32] <Roguehorse> ????
[06:33] <ianorlin> yeah but she has been having problems
[06:33] <Roguehorse> oh
[06:33] <ianorlin> at least I didn't have the nighmare scenario of having to leave scale to pick up my mom from mental hosptial
[06:33] <ianorlin> that would have not been fun
[06:34] <Roguehorse> is she doing ok?
[06:34] <DonkeyHotei> especially in all that traffic
[06:38] <ianorlin> she was not doing so many erratic things was hard to get anything done
[06:49] <Roguehorse> it happens to anyone
[07:21] <Roguehorse> what is that KDE program for making slideshows?
[07:27] <Roguehorse> got it
[07:35] <nhaines> Is there a KDE program just for slideshows?
[13:59] <Roguehorse> Good Morning =)
[15:09] <Roguehorse> what do I tweak in grub so tty1 is a better resolution than 640x480?
[15:11] <akk> tty1 after login shouldn't be a function of grub ... it's whatever upstart/systemd/init makes it long after the system is booted.
[15:11] <akk> Unless you're just trying to get the grub splash screen to be high resolution.
[15:11] <akk> (then it's not tty1 afaik, it's just the grub screen)
[15:47] <Roguehorse> so setting this won't do it?  GRUB_GFXMODE="1920x1080"
[15:47] <Roguehorse> instead of auto?
[15:52] <akk> I think that will change the resolution of the splash screen, not the screen you get after you boot.
[15:52] <akk> But I could be wrong, doesn't hurt to try it.
[15:53] <akk> I'm certainly no expert on grub, gave up on it not long after grub2 became mandatory.
[15:55] <Roguehorse> ah
[15:55] <ianorlin> I am not a grub expert either
[15:57] <Roguehorse> I think I need to add this line too:   GRUB_GFXPAYLOAD_LINUX=keep
[15:58] <Roguehorse> I'm just intrigued that it's even at 640x480, must be the Nvidia driver ..... it just updated on me a few days ago
[15:59] <Roguehorse> it's an older 9800GT card but works fine
[16:00] <Roguehorse> trying to pull eclipse and it's taking FOREVER!
[16:00] <akk> Eclipse does take forever to install, and then another forever to configure.
[16:01]  * akk has only used it for android, which itself takes at least five forevers even if you don't use eclipse for it
[16:01] <akk> I was so happy when I learned how to do android builds with ant so I could ditch eclipse.
[16:03] <ianorlin> texlive takes a while to install as well
[16:15] <Roguehorse> well, I might have to just kill it and try later
[16:16] <Roguehorse> I really don't need it right now anyway and I know where to get it
[17:02] <ianorlin> join ##hardware


[16:19] <pseubodot> The 14.10 netinst (on amd64 and i386) complains about kernel module version mismatch and cannot complete installation; ('anna: WARNING ** no packages matching running kernel 3.16.0-24-generic in archive'). Netinst build is 352 (dated 22-Oct-2014). Same build on ca.archive.ubuntu.com and us.archive.ubuntu.com
[16:21] <pseubodot> Is there a newer netboot.tar.gz available anywhere?
[20:59] <pseubodot> email sent.
[21:23] <infinity> pseubodot: I don't see why that would be.
[21:27] <infinity> pseubodot: Wait, which installer are you using?  The 14.10 netboot hasn't changed since release, and is using -23, not -24
[21:30] <infinity> pseubodot: Just tested a full install with the 14.10 netboot, and it went fine here.
[21:47] <pseubodot> infinity: thanks. where did you download it from?
[21:47] <infinity> pseubodot: From the archive.
[21:47] <infinity> pseubodot: More curious about where you got yours from. :)
[21:48] <pseubodot> IMAGE_URLS[0]="http://archive.ubuntu.com/ubuntu/dists/utopic/main/installer-amd64/current/images/netboot/netboot.tar.gz"
[21:50] <infinity> I just used linux and initrd.gz from the ubuntu-installer directory there, but that should match the tarball, I'd think.
[21:50] <infinity> Grabbing the tarball to see what's in it. :P
[21:50] <pseubodot> infinity: thanks. sorry for the trouble.
[21:51] <infinity> Same kernel, different initrd.  That's curious.  But maybe it was repacked or something.
[21:51] <infinity> I'll try with this one.
[21:51] <infinity> pseubodot: How are you booting that?
[21:51] <pseubodot> via TFTP, do you want the boot args?
[21:52] <infinity> Hrm.  Kay, the tarball is also -23, as it should be, and working fine here.
[21:53] <infinity> pseubodot: Are you sure you haven't replaced the kernel, or maybe are pointing to a different one by accident?
[21:54] <pseubodot> infinity: Pulled down the netinst tarball, untarred it somewhere, then moved the contents elsewhere for booting
[21:54] <pseubodot> infinity: I will download and try again, it may be a pebkac
[21:55] <infinity> pseubodot: It kinda has to be.  This is working fine here.
[21:55] <pseubodot> (the script untars it somewhere, but I push it in manually)
[21:55] <infinity> pseubodot: Well, working fine plus, as I said, that d-i build hasn't changed since Utopic's release.  I'd expect much more vocal anger from more people if it was broken. :)
[21:56] <pseubodot> infinity: :)
[21:58] <pseubodot> infinity: thanks again, sorry for the trouble.
[22:00] <infinity> pseubodot: S'ok.  I get pretty excitable when someone suggests d-i is broken in a released series. :)


[18:57] <smoser> hey.
[18:57] <smoser> if i bzr fast-export, i get all the merged commits
[18:58] <smoser> bzr nicely "nested" these commits
[18:58] <smoser> but exporting to git, i see lots of little commits that people did on branches that you could see with bzr log --include-merged
[18:58] <smoser> but generally were not bothered with
[18:59] <smoser> i'm willing to accept the loss of those commits to keep sane commit messages in 'git log'
[18:59] <smoser> any ideas?


[07:49] <smb> morning .+
[07:52] <ppisati> smb: morning [[:alpha:]]*
[08:43] <apw> smb, can you remember the incantation to upload a package to a different pocket to that it is intended for
[08:44] <smb> No, last time I tried to I gave up and just did the hack .changes trick
[08:46] <smb> apw, Most likely it could be "dput <host>:<release>"... But using it so rarely does not help.
[13:38] <apw> herton, is anything in particular holding lts-backport-natty from releasing
[13:38] <apw> it seems much behind its parent these day
[13:38] <herton> apw: nope, it's waiting to be copied to -updates
[13:38] <apw> herton, is that a recent thing or has it been waiting for a while ?
[13:40] <herton> it's recent, was ready only yesterday I think. The current update is being tracked on bug 848588
[13:40] <ubot2> Launchpad bug 848588 in kernel-sru-workflow "linux-lts-backport-natty: 2.6.38-11.50~lucid1 -proposed tracker" [Undecided,In progress] https://launchpad.net/bugs/848588
[13:40] <apw> herton, thanks, just trying to get this table down under a screen in height and that'll do it nicely
[14:10]  * ogasawara back in 20
[14:30] <apw> ppisati, is this italian?  "congelamiento de equipo"
[14:31] <tgardner> apw, doesn't that mean 'free gear' ?
[14:32] <apw> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/857962
[14:32] <ubot2> Ubuntu bug 857962 in linux "congelamiento de equipo" [Undecided,Incomplete]
[14:32] <apw> no idea, the whole thing is in foreign
[14:33] <apw> seems it is spanish
[14:33] <herton> it looks spanish, literally means equipment freeze, or hardware freeze
[14:33] <tgardner> yep, thats what google translated it as
[14:33] <cking> it's spanish
[14:34] <apw> ta
[14:34] <cking> Fldigi using cw decode and monitor the radio Mhz 50110 IC7000. After two screen freezes and reset to normal and allows me to Send this report "
[14:34] <cking> Fldigi using cw decode and monitor the radio IC7000 50110 Mhz. screen freezes and after two reset to normal and allows me to send this report
[14:42] <herton> spanish is very similar to portuguese (although there are significant differences), my translation may be not the most correct, but I would translate the bug description as:
[14:42] <herton> when using fldigi to decode cw and control the ic7000 radio hardware at
[14:42] <herton> 50110 Mhz. The screen freezes and after reset it normalizes and allows
[14:42] <herton> me to send this report
[14:53] <herton> *after two resets
[15:04] <brendand> bjf, sconklin - is the natty -proposed kernel going to be in verification next week (and therefore regression testing the week after?)
[15:07] <sconklin> brendand, yeah it actually should leave verification by the end of next week, it will start verification tomorrow (as soon as the build is done)
[15:18] <brendand> sconklin - so the plan is it will go to regression testing around October 10th?
[15:20] <sconklin> brendand, no, if it enters Verification tomorrow, and there are no complex regressions or other delaying factors, it should be ready for regression testing around Oct 7th
[15:28] <manjo> pgraner, can you pm me that url for the premier account ?
[15:29] <manjo> pgraner, apparently any number of people can reg using one url
[15:55] <ppisati> apw: yep, spanish
[15:55] <ppisati> apw: equipment freeze
[15:59] <apw> thanks :)
[16:00] <ppisati> just a coupld of hours late... :)
[16:29] <hggdh> bjf, smb: bug 861550 while testing 2.6.35-30.60
[16:29] <ubot2> Launchpad bug 861550 in linux "Maverick proposed: WARNING: at /build/buildd/linux-2.6.35/arch/x86/kernel/apic/ipi.c:109 default_send_IPI_mask_logical+0xb1/0xf0()" [Undecided,Confirmed] https://launchpad.net/bugs/861550
[16:31] <apw> hggdh, did any of the tests fails at all ?
[16:31] <bjf> sconklin, herton, ^
[16:32] <sconklin> ack
[16:33] <apw> sconklin, the warning there says that we asked to send an IPI to noone, it then returned ... its possible it benign
[16:33] <hggdh> apw: no
[16:35] <apw> sconklin, ^^ seems that none of the actual tests were affected either
[16:36] <sconklin> ok, good
[16:57] <nomadium> is there a way to recover the memory listed in SUnreclaim area?
[17:53]  * tgardner -> lunch
[17:55] <cking> hrm, S4 purple screen of resume doom
[17:58] <apw> cking, fun ...
[17:58]  * apw wanders off to a more comfortable location
[17:58] <cking> where the beers are perchance?
[18:13] <_ruben> wonder if this is an issue in the Makefile or some sort of dependency/kernel/whatever issue: http://paste.ubuntu.com/698634/
[18:40] <salty-horse> ogasawara, here?
[18:41] <ogasawara> maybe, my pet peeve is pings without content so I tend to ignore them.
[18:44] <salty-horse> sorry :( last we talked, I asked about inclusion of a driver (<http://ubuntuforums.org/showthread.php?t=1530962>) into the ubuntu kernel. you mentioned that the team prefers it to be included upstream. I contacted the author, who says he doesn't have time to do that (and that he tried before, and didn't get enough support). do you know of there's a process for adoption of such modules by regular kernel maintainers? is there a w
[18:44] <salty-horse> ay to convince ubuntu to still include it?
[18:50] <tgardner> salty-horse, wrap it in DKMS and upload to universe.
[18:50] <salty-horse> tgardner, I'm not a kernel hacker. just someone trying to get it integrated so the few people with that hardware could have working wifi without compiling modules
[18:51] <ogasawara> salty-horse: if upstream won't take it I doubt we'll want to take it separately due to the maintenance burden.  did the author comment what upstream's reasons were for not taking it?  alternatively, you could do as tgardner suggests.
[18:53] <salty_horse> ogasawara, the email only mentioned lack of experience and "vague answers" in regards for getting it into the kernel. I don't know what's the source of those answers