=== roadmr is now known as roadmr_afk === roadmr_afk is now known as roadmr === dkessel_ is now known as dkessel === tgm4883_ is now known as tgm4883 === roadmr is now known as roadmr_afk [05:18] doko_: Re https://bugs.launchpad.net/ubuntu/+source/openjdk-7/+bug/1389493 [05:18] Launchpad bug 1389493 in openjdk-7 (Ubuntu) "Package dropped pulse-java.jar, breaking some development environments" [High,Confirmed] [05:18] doko_: As far as I can tell it seems to be a largely cosmetic issue, but a sufficiently annoying one that we should resolve it. === doko_ is now known as doko [05:36] RAOF, I'm not sure how. just adding the old name as a symlink doesn't work either === roadmr_afk is now known as roadmr === roadmr is now known as roadmr_afk [06:10] doko: Urgh. === pitti` is now known as pitti [06:48] Good mornin [06:51] hello pitti [06:52] Does seahorse-nautilus really need to depend on seahorse-daemon? if not, we can sync === roadmr_afk is now known as roadmr === mitya57_ is now known as mitya57 === alexlist` is now known as alexlist === roadmr is now known as roadmr_afk === fabo_ is now known as fabo === roadmr_afk is now known as roadmr [09:10] now that Debian is frozen will Ubuntu default to syncing from experimental or should I file appropriate bugs for this to happen for the packages that I maintain? [09:11] +1 for Laibsch question, I hope the latter [09:15] No, we will not sync anything from rc-buggy (aka experimental) automatically. [09:15] Please use requestsync from ubuntu-dev-tools to request syncs. [09:15] happy to hear that, I hope you will consider sync from maintainer requests :) [09:15] wonderful thanks [09:16] yes, manually requested syncs are no problem, we just don't want to auto-import experimental stuff without checking [09:16] yes, seems legit, I would like to avoid that too :) [09:36] bug 1392236 it is [09:36] bug 1392236 in scanbd (Ubuntu) "please my packages from experimental" [Wishlist,New] https://launchpad.net/bugs/1392236 [10:06] who can say why plasma-desktop isn't transitioning from proposed? [10:06] I can see kwrited isn't happy about me removing the kwrited-data package which I'm confused about http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html [10:06] everything else should be ok [10:15] RAOF, hmm, would it help to place an empty pulse-java.jar there? === ara is now known as Guest56698 [10:41] Laibsch: We don't have a mechanism to sync all your packages from experimental; unless you fancy doing some hacking on auto-sync I don't expect to have one in the near future. Please just file explicit sync requests as needed for now [10:41] That is, per-upload [10:42] Easiest is if you get PPU rights or better for your packages, and then you can run syncpackage yourself :) [10:43] Laibsch: there is tool to do so in standard way to request syncs with the "requestsync" tool available from ubuntu-dev-tools in both ubuntu & debian. [10:44] xnox: He was already pointed at that [10:45] I just wanted to make it clear that the request in the text of bug 1392236 is not something that we actually have the technology put together to fulfil right now. [10:45] bug 1392236 in scanbd (Ubuntu) "please sync my packages from experimental" [Wishlist,New] https://launchpad.net/bugs/1392236 [10:48] cjwatson: I'd love to get that, but my request for @ubuntu membership was rejected in 2010 because I was contributing too much and had been doing so for too long a time (I kid you not!) [10:49] after that experience I said to myself "WTF" and rolled over and simply ignored the nonsense process and never retried [10:49] it is quite a bit of work and I only needed to waste my time on an application once [10:50] I have pretty high clearance on bug triage in LP and I am Debian DM but apparently I need to get that @ubuntu membership for what you are suggesting and frankly, after that experience in 2010 I cannot be bothered to waste my time on the application process once again [10:51] Laibsch: OK, just wanted to let you know about the parameters that are available for syncing [10:51] Laibsch: BTW it's not true that membership is required before PPU or other similar upload access [10:51] Laibsch: getting upload access *grants* membership as part of it [10:51] really? [10:52] Ubuntu processes evolve fast and have gotten complicated [10:52] Laibsch: this has been the case as long as I can remember [10:52] where is the doc describing the process? [10:52] https://wiki.ubuntu.com/UbuntuDevelopers [10:53] which links to https://wiki.ubuntu.com/DeveloperMembershipBoard/ApplicationProcess [10:53] I would generally say that developers should be taking this route rather than going through the general Ubuntu membership thing first [10:53] and again, that's pretty much always been the case - sorry if you were misadvised before [10:54] "Joining the Per-package Uploaders Check out the general requirements for Ubuntu Membership. " [10:54] yes, that means you need to meet the requirements [10:54] it seems to be a requirement to me [10:54] it doesn't mean you need to separately gain membership first [10:55] but I have to go through the nonsense one more time? seriously, how many times would you beg someone for a key when he told you you are TOO skilled and trustworthy? [10:55] you don't have to go to the people who do general membership [10:55] OK [10:55] that might help [10:55] ;-) [10:55] what this means is that the DMB will check for sustained and significant contributions as part of their process [10:55] I remember I had to wake up at 3 in the morning and sit around for two hours twiddling thumbs [10:56] to receive a rejection because I do too much [10:56] I am still thoroughly pissed off [10:56] yes, sustained and significant [10:56] so they check the same requirements, but you don't have to go through two committees or whatever [10:56] in my case too sustained (since 2005) and apparently too significant [10:56] :-/ [10:56] being granted any kind of upload access implicitly grants membership [10:57] (technically: because ~ubuntu-dev is a member of ~ubuntumembers) [10:58] I'm sorry you had a bad experience. I can't do anything about that, but I can suggest a more appropriate avenue that might yield better results [10:58] OK [10:58] that is appreciated [10:58] this really should not happen, I hope it never happened again, but I cannot be sure [11:00] I will keep my application efforts to a minimum this time, if I receive another rejection this time because "I did not proof my case" then that will be it for me. I only jump through so many hoops to be admitted as a volunteer [11:00] I left the community council in 2006, so I haven't been directly involved with the non-developer membership stuff since then ... [11:02] Laibsch: yeah, developer membership board focuses on checking / verifying sufficient technical skills and knoweledge of release process (to make sure one syncs/uploads the right things at the right time). Looking over your profile, it looks to me like you have sufficient technical skill to apply for PPU (per package uploader). [11:02] for the packages that you are the mainter off in Debian already. [11:02] and then you will be able to sync them yourself into ubuntu. [11:02] ps. I sit on the Ubuntu Developer Membership Board that grants such rights [11:02] Laibsch: i have never been involved in the Community governance, I gained my ubuntu membership via Developer Membership board but becoming ubuntu contributing developer first, and later a core dev. [11:03] well, cjwatson chaired the meeting / voted to approve me :-) [11:03] I'm sure that must help [11:04] Laibsch: nah, he was skeptical, but fair =)))))) === Zic_ is now known as Zic [11:05] Laibsch: if you make application wiki page, and email it in, we can review you on the 1st of December 19:00 UTC as per https://wiki.ubuntu.com/DeveloperMembershipBoard/Agenda [11:06] I hope I won't have to be present this time? [11:06] (one needs to apply at least 2 weeks in advance of the meeting) [11:06] that's again middle of the night [11:06] the times are not good for Asia-based people [11:06] like I said, my application effort will be minimal, including wiki page (I will create a very simple one) [11:10] 19:00 UTC is not possible for me to attend [11:10] that's again exactly 3 AM [11:10] sorry, I love Ubuntu, but not that much [11:10] Laibsch: those are generally irc interractive meeting. [11:10] not after that experience [11:10] Laibsch: you can email, and request for an email application. [11:10] good [11:10] I wonder where my old wiki page went? [11:10] the meeting on the 15th will be at 15:00 UTC [11:11] I'd like not having to redo it [11:11] Laibsch: if that's any better for interractive application. [11:11] If you happen to know the URL, try appending ?action=info to it [11:12] here it is: https://wiki.ubuntu.com/RolfLeggewie [11:12] found it [11:12] deeply buried in google ;) === greyback__ is now known as greyback === MacSlow is now known as MacSlow|lunch [12:50] does anyone have an idea why the fix for debian bug 169922 does not seem to be in ubuntu ? [12:50] Debian bug 169922 in mount "umount doesn't remount fs read-only if force option is also used" [Normal,Open] http://bugs.debian.org/169922 [12:51] * ogra_ tries to make adb on the phone actually force a readonly re-mount before killing the system on "adb reboot" ... seems "umount -f -r -a" does not work (nor does it work with a single mountpoint) [12:52] according to that but this should work since 2004 [12:54] s/but/bug/ === MacSlow|lunch is now known as MacSlow [13:22] ogra_: I regularly do "mount -o remount,ro /", and that works fine [13:22] (as both dual-boot and the emulator are r/w by default, annoyingly) [13:23] pitti, / is ro anyway ... [13:23] pitti, http://paste.ubuntu.com/8986920/ [13:23] or [13:23] root@ubuntu-phablet:~# umount -f -r /userdata [13:23] umount: /userdata: target is busy [13:23] ah, busy [13:23] right [13:24] the bug above suggests this should work though [13:24] even when busy [13:24] well, if there are processes still having open files on that (for write mode), how is it supposed to work? [13:24] (and indeed it is busy) [13:24] you'd break all the running processes [13:25] thats fine, we call reboot anyway (dircet kernel call) [13:25] (but I guess that's intended) [13:25] *direct [13:25] i dont care about the state of the processes, but i do care about the integrity of the fs [13:26] we see a lot of file corruption on the phone ... one of the reasons is "adb reboot" ... [13:26] the logical option would indeed be to make it call /sbin/reboot ... but that takes long ... i would like ot keep the convenience of speedy reboots in adb [13:27] ogra_: so perhaps as a first mitigation sync; reboot -f? [13:27] (but yeah, forcibly unmounting/ro mounting would of course be betteR) [13:27] the code already calls sync ... doe reboot -f gain me anything over the direct kernel reboot call ? [13:27] *does [13:28] ogra_: no, reboot -f is pretty much that -- don't go through init, just reboot the kernel; that's what I meant [13:28] yeah, well, that is what happens already [13:28] ogra_: hm, sysrq+u does forced r/o, I wonder if one can trigger that by some other means [13:28] with the init layer ripped out inbetween [13:28] MNT_FORCE (since Linux 2.1.116) [13:29] Force unmount even if busy. This can cause data loss. (Only for NFS mounts.) [13:29] hmm [13:29] umount(8) also only talks about NFS [13:30] well, the bug seems to actually use a real device [13:30] ogra_: ooh! [13:30] https://www.kernel.org/doc/Documentation/sysrq.txt [13:31] ogra_: echo u > /proc/sysrq-trigger [13:31] hah ! [13:31] * ogra_ hugs pitti [13:31] (well, open() and fputc('u') in C, of course) [13:31] ogra_: at least sysrq+u seems to work fairly reliably for me to reboot my machine after a crash and save the fs [13:31] root@ubuntu-phablet:~# echo u > /proc/sysrq-trigger [13:31] root@ubuntu-phablet:~# touch /userdata/foo [13:31] touch: cannot touch ‘/userdata/foo’: Read-only file system [13:31] \o/ [13:32] touché [13:32] lovely [13:32] ogra_: so, write 'u', sleep(0.5), reboot()? [13:33] or maybe even just (1); the whole reboot takes long enough that an extra .5 s for your data safety probably doesn't matter [13:33] well, adbalready has: [13:33] 188 execl("/system/bin/vdc", "/system/bin/vdc", "volume", "unmount", [13:33] 189 getenv("EXTERNAL_STORAGE"), "force", NULL); [13:33] which it calls right before rebooting [13:34] i guess i can just replace these two lines [13:34] so you are saying that this doesn't work, or it doesn't apply to our internal storage, or we need to do it for other mounts? [13:34] we dont use /system stuff in ubuntu indeed :) [13:34] nor do we use vdc ... [13:34] that code is a no-op currently [13:35] aah [13:35] but in adbd it is executed right before the reboot call to the kernel [13:35] ogra_: so yeah, sounds good [13:35] I'd still give it a second to actually sync and remount [13:35] so for our usecase just writing to proc instead sounds good [13:35] yeah, i can add a sleep [13:36] that will still be miles better than using upstarts reboot though :) [13:36] right, I didn't even realize that adb reboot didn't use the "proper" reboot [13:36] it takes long enough, after all (some 5 s here) [13:37] and I use it all the time [13:40] pitti, hah, i gues you never used a normal reboot then ... thats more in the area of 20s [13:41] ogra_: well, I did (long-press power button) [13:41] but I didn't really pay enough attention to wonder about the time difference [13:41] ogra_: but these days most of what I do with the phone is to test/fix adt-run :) [13:41] it is quite significant ... i always prefer adb reboot [13:41] if i do work on the phone at least [13:42] ogra_: so, thanks for fixing that! [13:42] well, thanks for getting me on the righ track !! [13:42] (i wouldnt have thought about sysreq ever) [13:59] smoser: ok, SRU for bug 1391354 uploaded (it's fine in vivid) [13:59] bug 1391354 in systemd (Ubuntu Utopic) "Failure to boot ephemeral image for Utopic Fast Installer deployment: no ID_PATH for iSCSI device any more" [Undecided,In progress] https://launchpad.net/bugs/1391354 [14:24] wgrant, heyo -- I have a bzrlib script that I would ideally like to run even faster -- it's intent is to delete invalid tags. http://paste.ubuntu.com/8987882/ Is there a cleverer way to do this? (Or can you point me at someone else that would know?) [14:25] cjwatson, xnox: what about the possibility not to have to attend the IRC meeting? one of you mentioned a mail interview process?! [14:26] Laibsch: yeah, in the application submission email you should state that you cannot attend either irc meeting times and wich to be processed via email. [14:27] mterry: I don't know bzrlib well at all, but I'd look for a bulk revision-id lookup method. [14:27] well, I might be able to attend but I don't want another night session. Even 1500 UTC is 23:00 here or even 00:00 if I am in Tokyo at the time and if it takes two hours like it did last time then I don't want that [14:29] mterry: well that script is fast if the branch you point it at is local, rather than remote. [14:30] mterry: so i'd clone it to a temp location first, find all tags to delete, and then delete them from target. [14:31] it's equivalent of $ bzr tags | grep ? | cut -d\ -f1 | xargs -L1 bzr tag --delete [14:31] xnox, yeah that might be the best solution, I was hoping to do a nice bzrlib thing [14:31] xnox, but shell always wins :) [14:31] mterry, check out http://people.canonical.com/~mwh/bzrlibapi/bzrlib.repository.Repository.html#all_revision_ids [14:31] xnox, that was the first thing we were doing, and it was _slow_ ;) [14:32] Saviq, oh really? [14:32] Saviq, just two bzr requests, I would expect it to be better [14:32] mterry, one request per tag, no? [14:33] mterry, `bzr tag --delete` does not seem to allow multiple tags (at least per man) [14:36] xnox: I basically left my old application page from 2010 as is and only added a paragraph to the top explaining why I did so. https://wiki.ubuntu.com/RolfLeggewie What are the next steps? Send e-mail to devel-permissions@lists.ubuntu.com and request for becoming a PPU dev? [14:36] when merging a package from Debian closes outstanding Ubuntu bugs, should those be listed in the changelog ? [14:36] caribou_: You can add "LP: #123" in the changelog [14:36] Launchpad bug 123 in Launchpad itself "There's no direct way to see the project info when translating it" [Medium,Fix released] https://launchpad.net/bugs/123 [14:36] similar to "Closes: #123" [14:36] Laibsch: yeah, that's what I meant [14:37] Laibsch: I know that, I just want to know if this is part of a normal merge activity [14:37] closes is for the Debian BTS, LP: for Launchpad [14:37] oh, you are wondering if you need to leave the changelog intact? [14:37] I'm not sure I understand the question [14:39] mterry, yeah, looks like pulling all_revision_ids() and matching to tags would be faster [14:43] Laibsch: when updating the changelog during a merge to the development version and the merge brings in patch from debian that fix existing bugs,should the changelog flag those bugs with (LP: #{bugno}) === caribou_ is now known as caribou [14:43] caribou_: add lp: #N reference in the debian/changelog, upload to debian, the rest will happen. [14:43] I would say I should, just need confirmation [14:44] caribou: you can add lp:#N references, if you can, during merge/before uploads. [14:44] xnox: "upload to debian" I suppose upload to ubuntu [14:44] xnox: I believe he wants to know if he should fiddle with the changelog when the debian maintainer forgot to flag the LP bug [14:44] caribou: otherwise you will need to close bugs yourself. [14:44] caribou: don't modify other entries, just your own. [14:44] Laibsch: nope, I'm merging a package from debian into Ubuntu Vivid [14:44] xnox: indeed [14:45] caribou: e.g. "* merge from debian, remaining changes: [14:45] * foo bar [14:45] xnox: I meant in the section I'm adding following the merge [14:45] * Changes in debian fix LP: #1, LP: #2 [14:45] xnox: ok, that's what I wanted confirmed [14:45] caribou: yeah. [14:45] xnox: I basically left my old application page from 2010 as is and only added a paragraph to the top explaining why I did so. https://wiki.ubuntu.com/RolfLeggewie What are the next steps? Send e-mail to devel-permissions@lists.ubuntu.com and request for becoming a PPU dev? [14:50] mterry, you there? connection issues it seems? [14:50] mterry, if you didn't get it, there's a branch.repository.all_revision_ids() [14:51] that can be matched against tags [14:53] Saviq, yeah I found that, am working on revision (got sidetracked by a wizard issue) [14:53] Saviq, thanks [14:54] mterry, no pressure, just wasn't sure you got the msg [14:54] Saviq, I hadn't [14:54] Saviq, I am having dumb irc problems indeed :( [14:55] Saviq, tell me if this is faster: http://paste.ubuntu.com/8988295/ [14:56] still seems slightly slow to me, but I think that's just my connection today [14:56] locally is very fast [14:58] mterry, http://pastebin.ubuntu.com/8988345/ [14:59] it's very slightly slower than the original one with hardcoded list [14:59] mterry, so it's great [14:59] Saviq, heh [15:00] Saviq, well once we feel comfortable with this, please replace your copy of the script in chinstrap [15:00] mterry, yup I will [15:00] mterry, I'll just add some logging and display for when you can't write to the branch [15:21] mhall119, hmm... how is it that sessions that were supposed to start at 1400 UTC are already finished¿? [15:24] Saviq: Because it's 15:24? [15:25] Saviq: 'date --utc' is your friend. :) [15:26] infinity, d'oh, I'm +1 now, not +2 ;) [15:26] damn DST [15:49] I had in the past always been able to simply swap out my HD, put it into a different computer and boot my old system from it. This seems no longer to be the case. what do I need to now? === Laibsch1 is now known as Laibsch [15:52] Saviq: lol === Spads_ is now known as Spads [15:54] oops, wrong channel [16:31] doko: FYI, regresssion in https://jenkins.qa.ubuntu.com/job/vivid-adt-python3.4/7/; (test.test_pyexpat.HandlerExceptionTest) [16:31] it was auto-synced, so no mail notification to you specifically [17:04] pitti, succeeds on the buildd, and currently I can't see anything network specific [17:07] doko: no, indeed; test.test_pyexpat.HandlerExceptionTest doesn't sound network specific at all, neither does "RuntimeError: a" === rickspencer3_ is now known as rickspencer3 === henrix_ is now known as henrix [17:35] smoser, infinity: btw, now would be a good time to reboot the wolfe host, or the remaining VMs (I suppose if I just reboot them from "within", they won't get teh changed qemu RAM config) [17:36] * pitti slips in a quick dist-upgrade === rcj` is now known as rcj === Spads_ is now known as Spads === Spads_ is now known as Spads === rickspencer3_ is now known as rickspencer3 [18:33] pitti, you rock. [18:33] thank you. [18:33] oh. i meant thank you for the help on that iscsi issue. [18:33] pitti, i'm sorry, wrt wolfe, what do you need ? === Adri2000_ is now known as Adri2000 === Spads_ is now known as Spads === GridCube_ is now known as GridCube