=== Three is now known as Three_Laws_Safe [01:04] tassadar, I think the android kernel is the one used, isn't it? [01:07] ptl, it is, but it has been modified to work with ubuntu better. === zz_chihchun is now known as chihchun [08:00] good morning [09:06] sigh.... and now the touchscreen doesn't work :( [11:11] hi... I'm trying to flash the rootfs.img image to my 32GB nexus 7... "fastboot flash userdata rootfs.img" fails with "error: cannot load..." [11:12] any idea why that'd occur ? [11:12] which rootfs.img is that ? [11:12] the sha sums check out [11:12] (where did you get it) [11:12] it's the one that the installer downloads [11:12] is it a 3G model ? [11:12] no [11:12] wifi [11:12] I didn't know there was a 3d model lol [11:13] http://hwe.ubuntu.com/uds-r/nexus7/32GB/rootfs.img [11:13] well, bug 1079729 [11:13] Launchpad bug 1079729 in ubuntu-nexus7 "Ubuntu uninstallable on 32GB 3G Nexus 7" [High,Confirmed] https://launchpad.net/bugs/1079729 [11:13] ah [11:13] not sure if all 32G models have the changed partitioning [11:13] I have a 16GB model too [11:13] I just figured that my experimental tablet should have more space [11:14] thanks for the help :) [11:14] the changed partitioning shouldn't affect *flashing* though [11:14] there are some experimental raring images, the next build should have the install fix [11:14] bootloader maps 'userdata' to the right partition [11:14] yeah [11:15] if the image is bigger than the partition ? [11:15] that would surely affect flashing [11:15] it shouldnt be [11:15] it's quite unlikely the image is bigger than the biggest partition on the tablet ;) [11:15] true ;P [11:16] what is the exact error you get though? [11:16] "error: cannot load..." doesn't tell much :P [11:16] error: cannot load './rootfs.img' [11:16] ^^^ exact error [11:16] I am doing this on an ODROID-X [11:16] that may make a difference [11:17] that sounds more like the rootfs.img you are trying to flash is missing from the directory you run the command from... [11:17] it flashed the bootloader fine [11:17] I can assure you it's in the right directory [11:17] and that the command is being executed in the right place [11:17] * aquarat rechecks anyway [11:17] yup [11:18] so many people just get that stuff wrong, so better to verify, hehe [11:18] of course [11:18] I make stupid mistakes sometimes [11:19] I can try giving fastboot an absolute path [11:19] but as I said, the boot image flashed correctly [11:20] nope, that doesn't work either [11:21] the interesting thing is that it's exactly the error it gives if you do e.g. 'fastboot flash userdata nonexistant.img' [11:22] I could try the normal installer again === chihchun is now known as zz_chihchun [11:23] installer dies too [11:24] is your disk full or some such ? [11:24] disk has 578MB of space remaining [11:24] what os are you using? [11:25] linaro variant of ubuntu [11:25] intended for the origenboard [11:25] I should probably just try this on an x86 desktop [11:25] * ogra_ doesnt think the installer was ever tested on arm [11:25] it's not really the installer [11:26] it's fastboot [11:26] aquarat: does the user in question have read access to the file? [11:26] no reason for it to fail though [11:26] it gives the same, unhelpful error if it doesn't [11:26] yes... sha256sum works on the file [11:26] and I've chmodded it to 777 just in case [11:26] funky [11:26] pitty fastboot doesn't have a -vvvv [11:26] not even a -v :) [11:27] uh huh :( [11:27] did you use the packaged fastboot from the archive/PPA ? [11:28] er... I don't know... I just typed "fastboot" in the terminal and it responded [11:28] i know for sure that i can flash my nexus fine from my raring chromebook [11:28] using the fastboot package [11:28] "android-tools-fastboot" [11:28] yep [11:28] is the package [11:29] ah well... I'll try later from an x86 machine [11:29] and let you know :) [11:29] k [11:39] does the touchscreen require any trick to work ? [11:39] I mean to work with X [11:40] the kernel driver reports events but it seems that X simply ignores them [11:45] fmoreau, which image is that using? your debian one? [11:47] lilstevie: yes. [11:47] which hw? [11:48] fmoreau, last I looked debian doesn't have all the multitouch enhancements that canonical have put into evdev [11:48] fmoreau, you may have to use one of the multitouch libs available [11:50] lilstevie: are those enhancements n7 specific or are they in their generic evdev driver? [11:50] kulve, against the generic evdev driver [11:50] lilstevie: multitouch ? but is that required to make the touchscreen work with "single" touch mode ? [11:51] fmoreau: I noticed that my Xorg's evdev driver didn't understand the evdev from the kernel. I used mtev driver for X.Org and with that it worked in the multitouch mode [11:51] fmoreau, I haven't looked closely at the n7 touch driver but 99% of these android devices touch screen drivers do not report in "single touch" mode only with multitouch protocol [11:51] lilstevie: I see thanks for those hints. [11:51] I would use mtev as kulve said [11:52] kulve: hmm, I can give it a try thanks [11:52] hmm. ubuntu's Xorg evdev driver requires libmtdev1 [11:52] that is what I was using back with the SGT7" with 11.04 [11:54] fmoreau, https://launchpad.net/ubuntu/raring/+source/ubuntu-defaults-nexus7/0.33 [11:54] there is a rootfs/uusr/share/X11 dir in that package [11:54] grab the content [11:55] xorg recognizes the touchscreen as mouse without these files [11:56] ogra-cb_: I already have that one: http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/raring/ubuntu-defaults-nexus7/raring-proposed/view/head:/rootfs/usr/share/X11/xorg.conf.d/21-nexus7-rotation.conf [11:56] and looking at Xorg.log, it doesn't seem to be seen as a mouse [11:57] see for example: http://pastebin.com/Z6RXmc8Y [11:58] yeah, looks fine [12:06] xnox, so i'm wondering ... spitting out three images for the nexus7 (8/16/32G) will eat a lot of space on cdimage ... if we would instead provide the raw tarball and call make_ext4fs from usb-creator we could save that [12:07] but would lose oversized checking indeed (or would have to put it into usb-creator too) [12:07] ogra-cb_: true. what about the bootimg? is it the same for all three? [12:07] it can be, yeah [12:07] ogra-cb_: with iso's we already do a bit of unpacking & shuffling around. [12:08] it would indeed mean more instructions for manual installing people [12:09] ogra-cb_: well, what I am hinting at is ship a flashable 8GB image, but make usb-creator repack it for 16 & 32. [12:09] yeah, thats definitely doable as well [12:09] 8G will become pretty rare in the future [12:13] well yeah, it's no longer available for sale [12:13] there is now a model with 3G though =) [12:13] i know [12:13] just fixed a bug for it [12:14] (different partitioning) [12:14] nexus 4 is sold out =( [12:14] it will return ... just be patient [12:14] * ogra-cb_ would rather have a nexus 10 [12:15] * Tassadar would rather have all of them [12:15] heh [12:15] well, the nexus 10 is essentially a chromebook in a different shell [12:15] fmoreau: the latest upstream xorg evdev driver is using mtev and ubuntu has only one patch on top of that (use-sigsafe-logging.diff) so maybe you just need to upgrade your Xorg evdev driver? [12:16] ogra-cb_: are we doing nexus10? [12:16] so it should be reallly easy to get ubuntu running [12:16] xnox, not to my knowledge [12:16] hmm, I sent patch to kernel-team mailing list yesterday, but it did not show up in the mailing list archives [12:16] I wonder where it went Oo [12:17] kulve: yes. I'm just giving mtev a try to see if that fixes the issue. If so, I'll do what you suggested. Thanks ! [12:17] but nobody stops a community image (apart from infinity who will cry about all the builds and only a single livefs builder) [12:17] Tassadar, are you subscribed ? else it will get into moderation first [12:18] oh, that I am not [12:18] you should have gotten an answer mail telling you yours waits for moderation [12:19] nothing like that [12:19] spam filter catched it ? [12:19] no, checked that [12:20] well, probably ask in #ubuntu-kernel [12:21] Can anyone decipher https://launchpadlibrarian.net/123744966/buildlog_ubuntu-raring-armhf.gmp_2%3A5.0.5%2Bdfsg-2ubuntu2_FAILEDTOBUILD.txt.gz for me? It's a new failure from what should have been an unrelated upload; it built three weeks or so ago. [12:21] (It also failed on amd64 due to what appears to be a compiler configuration bug, but not one that seems likely to be related to ARM.) === albert is now known as Guest44735 [12:24] hmm, linker assembly issues, i guess that needs doko or infinity [12:27] kulve: is the latest upstream evdev driver you were refering is 2.7.3 ? [12:29] cjwatson, any hints on https://wiki.ubuntu.com/ARM/Thumb2PortingHowto ? [12:30] o wonder if USE_THUMB=1 possibly means use thumb1 [12:30] s/o/i/ [12:30] wouldn't it have failed three weeks ago if it were a thumb issue? [12:30] or am I missing something there? [12:30] fmoreau: I just checked from the git browser, so the most fresh commit [12:30] dunno, was it changed inbetwween ? [12:30] * ogra-cb_ grabs the source [12:31] it had USES_THUMB=1 then too [12:31] ah, k [12:31] I sponsored a patch from wookey, but not one that would have affected armhf [12:31] there was a libc upload inbetween though, wasnt there ? [12:32] three actually [12:33] I guess I'm not sure what isn't ARMish about "str r1,[ r0 ]" [12:33] nothing that looks related though [12:33] ah, binutils got updated too [12:33] on wed. [12:34] "- arm, aarch64 and x32 updates." [12:35] i guess its either a buildd hiccup or that upload [12:36] * ogra-cb_ grumbles about the chromebook designers [12:37] as shiny as having a normal key on the kbd for power ... putting it where the del key normally would be is really annoying [12:37] s/power/power is/ [12:39] ogra-cb_, heh the transformer keyboard has a lock key there, I ended up remapping the key at a driver level back to delete cause of accidental sleeps [12:39] and at one stage there was a bug with sleeping, where it would not come back [12:40] well, ubuntu sets [pwer to pop up a window by default, so at least i dont go to sleep twice an hour [12:40] yeah that isn't too bad [12:40] but i have to cancel the sutdown countdown all the time indeed [12:40] heh [12:41] there was never any hesitation with the sleep button, just off it went [12:41] yeah, that one just calls pm-suspend [12:41] you should be able to disable it in dconf-editor though [12:42] was easier to just remap :p [12:42] yeah, i dont thinnk i can easily remap power [12:42] it will very likely stiill sent the power event [12:43] yeah probably [12:43] at least with the sleep button it is just a scan code [12:44] and the driver doesn't even report most of them without changing them cause KEY_ASUSDEC_* scan codes do not line up with what evdev or any other sane driver will be expecting [13:28] * ogra-cb_ hugs xnox [13:28] ? [13:28] plymouth :) [13:28] oh, you wanted it for arm? [13:29] well, i wanted to have the new version before going on to debug the nexus [13:30] since thats supposed to have a bunch of fixes for console= handling [13:30] * xnox just doesn't like the 300kB of text here http://people.canonical.com/~ubuntu-archive/proposed-migration/update_output.txt [13:30] yeah [13:30] i would have jumped on plymouth on monday [13:30] if you hadnt done it ... [13:30] yeah about the console= handling. I am not entirely convinced that our vt_handoff patches interfere with that or not. [13:30] this week is simply nexus image build week for me [13:31] well, if it still fails i'll do some tests [13:31] i have high hopes it gets better though [13:35] fmoreau: btw, I never got the fastboot flash -S working, so tell me if it works for you. Currently I'm creating 4GB file system but it has to have at most ~700MB of data on it or the flashing fails [13:36] hmm.. I did try it only with the original fastboot. Maybe the Android MR1 updated also the fastboot? [13:36] Is it bootable yet? I would try to make instalation zip for recoveries, like android ROMs do [13:37] * xnox ponders if it matters whether or not the tablet is OTA updated to the latest (post nexus4) multi-user android 4.2 firmware update [13:37] the bootloader was updated in 4.2 [13:41] ogra-cb_: did you update the android side of nexus7 ever? [13:48] * xnox lols over surface pricing [13:48] * Tassadar lols over the actual free memory of 32gb surface [13:50] kulve: do you mean that fastboot can load an image of 4Go if it's full of zero ? [14:06] fmoreau: the file itself is smaller, but somehow the imag is still 4GB. I don't know the details, but make_ext4fs (iirc) makes it happen [14:08] will try to use make_ext4fs then. [14:09] kulve: the touchscreen is finally working :) well almost, because for some reason the Invert{X,Y} and swapAxes options are not working [14:09] it's a bit buggy though, I can give you details later, when I have a keyboard instead of a phone :) [14:10] fmoreau: which xorg driver? [14:10] latest evdev [14:10] as you suggested [14:11] ok, great [14:14] kulve: when you'll get a keyboard, please send the gory details so I can try to make it works eventually :) [14:17] fmoreau: did you upgrade to android 4.2? [14:17] for the kernel ? [14:17] xnox, not beyond the upgrade i got directly at startup of the device [14:17] fmoreau: for the fastboot [14:18] ogra-cb_: ack. [14:21] kulve: nope I'm still 4.1 [14:22] well, maybe I'll try upgrading on sunday.. [14:25] so does the existence of nexus 7 images mean that nux is fixed and i can remove the pinning? [14:26] nope [14:26] it just means that the images currently ship with a broken nux [14:27] and the current one is still to big, only lucky people for which fastboot -S works can use it atm [14:28] that part should change with the next build though, nux not yet [14:34] ogra-cb_, what is the issue with -S exactly? Unknown bug? [14:35] janimo, yeah [14:35] you get a corrupt unmountable fs on the target disk [14:35] i suspect some dicrepancy between the fastboot on the device and the PC [14:35] *dis [14:36] ogra-cb_, well the bootloader ROM versions are different across devices [14:36] and some Android upgrades also change them [14:36] right [14:36] maybe we could find out if only certain versions have it [14:37] Having an android style .zip upgrade tarball has its advantages I guess [14:37] fastboot may not be as well tested [14:37] yeah, probably [14:38] well, we would still use fastboot for flashing the zip [14:38] adb to the recovery [14:38] but maybe neds rooting unless the zip is google's, I don't know [14:39] you cant rely on the fact that all devices we'll support will have actual recovery available [14:40] yeah, needs custom recovery to flash updates not-from-google [14:40] which means unlocked bootloader [14:40] well, we always need an unlicked bootloader [14:41] heh [14:41] *locked [14:41] right, oem unlock is a given for our case [14:42] but if you run into devices like i.e. the ac100 where an update makes recovery a no-op you are screwed relying on a recovery mode [14:42] fastboot flash is simply wjat all oem unlocked devices know [14:44] i think the grub/casper-lupin way is the way for the future though (13.10 and later), that should give us other compression abilities [14:44] so then this issue wouldnt bite us anymore [14:44] for 13.04 we should simply just keep the seed small [14:46] can someone point me out the location of the fastboot repository ? [14:46] I don't know if it's me but I'm always having hard time to figure out where the stuff are for android project... [14:48] https://android.googlesource.com/platform/system/core/ [14:48] its in here [14:55] thanks [14:56] sad... can't do a simple "make" to build fastboot. [14:57] * Tassadar looks at 4 android repositories on his disk, each one to build just one small part [14:57] yeah... [14:58] :) [15:04] just apt-get source the package, then replace the .c files as needed/wanted [15:05] ogra-cb_, is this a new upstream? [15:05] though i think we have the code from a very recent master checkout [15:05] doko, what ? cjwatson's gmp FTBFS ? [15:05] i doubt that [15:12] diwic, did any of the pulse and alsa bits from the nexus7 defaults package into rating already ? [15:12] *go into [15:13] ogra-cb_, no [15:13] k, good, since i didnt remove them from the package when i uploaded it [15:14] if that stuff goes into regular packages, please let me know so i can clean up the default package [15:18] ogra-cb_, ok, so far I think it's quite specific [15:19] as the pandaboard stuff or the ac100 bits are [15:19] we still ship their ucm files in the regular packages [15:22] Yeah, I've always wondered why we do that, especially for x86... [15:23] achiang, no news on the no-sound-before-s3 issue? [15:23] fmoreau: make_ext4fs comes in a package android-tools-fsutils (take it from the ubuntu's repos). Then create the image like this: "sudo make_ext4fs -s -l 4G rootfs.img /path/to/roofs". For me it failed if I had the normal /dev files there, so my /dev is empty. But I also have the automount /dev option turned on in the kernel [15:24] diwic: sorry, i didn't get a chance to escalate to nvidia yet. i will do that soon [15:25] kulve: thanks. I'm actually facing the issue with /dev/. [15:25] doko: of gmp? no, just a trivial patch [15:25] was looking at the code of make_ext4fs [15:26] fmoreau: is it option for you to turn the kernel option on? It stupid anyway to have some initial files there as tmpfs is probably mounted to /dev quite soon anyway [15:26] +typofix [15:28] kulve: are you talking about this option CONFIG_DEVTMPFS_MOUNT ? [15:29] achiang, ack [15:29] fmoreau: I think so. [15:29] kulve: then it's already on [15:30] then you should be just fine with empty /dev as the kernel will mount it right after it mounts the rootfs [15:30] kulve: ok [15:30] thanks [15:31] DEVTMPFS_MOUNT: "Automount devtmpfs at /dev, after the kernel mounted the rootfs", yeah that's it [15:32] cool [15:33] but make_ext4fs should handle file devices... I'm wondering why it's failing. [15:33] s/should// [15:38] perhaps I'm running an old version of make_ext4fs but the source I'm looking at does handle special dev files. [15:42] and I've no idea how to rebuild make_ext4fs... [15:42] anyways I'm going to try to boot with an empty /dev [15:45] kulve: works fine :) [15:52] kulve: BTW, make_ext4fs is only used in order to create a ext4 fs without root permission or does it provide more ? [16:13] fmoreau: "without root permission"? I've used it to create 4GB image that fits into the 700MB flashing limit. And I'm using 4GB without any particular reason. I think 13GB should be fine for 16GB n7 [16:19] fmoreau: you mean why mkfs.ext4 isn't used? [16:20] Tassadar: yes. But I think that the answer was given by kulve when he suggested to use '-s' switch [16:21] kulve: doing : make_ext4fs -s -l 13G rootfs.ext4 rootfs => rootfs.ext4 794M [16:22] it does not create normal ext4 image, but special "sparse" image [16:25] Tassadar: does the "sparse" image need a special fasboot's option ? [16:25] when flashing it. [16:25] no, it is the format for fastbooot [16:26] it cannot flash normal ext4 image I think [16:26] as you can see, it is only as big as are the data in it [16:26] Tassadar: well I'm flashing normal images. [16:27] I don't think flasboot reads the content of the images actually [16:28] Tassadar: but sparse image can't be mounted on the host [16:29] exactly, that is why I think fastboot actually reads the image [16:30] which value should I pass to fastboot with '-S' ? [16:32] ogra-cb_ said 630M I think [16:33] sudo fastboot flash -S600M userdata ../rootfs.ext4 [16:33] Invalid sparse file format at header magi [16:33] ... [16:33] weird. [16:34] maybe you have too old make_ext4fs..? [16:35] no idea, and those tools have no version num :-/ [16:47] infinity: around? To generate cloud ARM images for machines that need mkimage wrappers to netboot, I'm going to need to hardcode load addresses and mkimage calls into the image generation scripts. Which is horrible. What do you think about modifying flash-kernel to be able to produce images for named boards, but to stop short of "installing" them? [16:48] Eg. "flash-kernel --write-uImage-only -o /where/I/want --machine '...' [16:48] Looks like that'll need some surgery to flash-kernel though, and we'll want to sync with Debian on that [16:51] fmoreau: for me all sizes to -S failed. Give the image that you can flash without -S with e.g. "-S 256M". It is then sent and flashed 256M at a time [16:52] without -S you should be able to flash also normal ext4 images (less that 700M). -S understands only the sparse images [16:53] I'll try to make -S work since I'd like to use all space available on the flash. [16:53] my wild guess is that the fastboot in n7 doesn't understand the -S and flashes all pieces to the start of the partition and then the kernel can't mount it because in practice there is only the last piece of the image [16:54] my wild try is to use all latest version (including the bootloader) and hope that it will work. [16:54] fmoreau: I would first flash the android 4.2 and only then try with the -S. But I'm guessing that the new fastboot wouldn't work with -S either.. [16:55] I would too like really much to get the -S working.. [16:56] I'm going to try the new bootloader from 4.2 [17:03] kulve: with bootloader v4.13, I also got this: "Invalid sparse file format at header magi [17:03] " [17:03] then [17:03] sending sparse 'userdata' (443531 KB)... [17:03] OKAY [ 61.174s] [17:03] writing 'userdata'... [17:03] FAILED (remote: (NotSupported)) [17:04] that shouldn't happen if you give it the image created with make_ext4fs [17:04] image created with "make_ext4fs -s -l 13G rootfs.ext4 rootfs" [17:05] ohh wait [17:05] 443531 KB? [17:05] :P [17:07] the actual file size doesn't need to match the partition size [17:08] yeah, but he says his image has 790MB === forcev is now known as FunkyPenguin [17:11] ok this time the image has been flashed successfully but the kernel panic when mounting the rootfs. [17:12] fmoreau: yeah, that happens when the -S doesn't work properly [17:12] i.e. that's what I get always [17:12] ok [17:12] but sometimes it might work, so I'm going to try a couple of times. [17:13] somebody claimed that it might work occasionally but I tried 10 times in a row without luck.. [17:14] I'd like to try the latest version of fastboot but seems to be painfull to build. [17:15] I doubt you can flash it [17:15] fmoreau: what distro do you have? [17:16] bricking the bootloader could brick the whole device [17:16] it will brick the whole device [17:17] it has already happened several times on XDA [17:17] but he means "fastboot" as the program on PC, not the bootloader [17:18] it won't let you flash a bl not signed by google anyways (N7 that is) [17:18] I think the problem is that the fastboot on the device side doesn't understand getting the image in pieces. PC side is probaby working as expected [17:19] that doesn't explain why it works on some devices though [17:19] RaYmAn: I think you can just write whatever you want the if you get the linux running? [17:20] well, technically speaking, yes, you can. However, tegra bootrom won't accept it because it's not signed/encrypted/checksummed in the right ways & places [17:20] Tassadar: debian [17:20] but you can't with flashboot (which incidentally does all the fancy signing/encryption/checksumming for you) [17:20] *fastboot [17:20] I can build it for you if you want [17:20] yeah, so you can flash it but it won't be loaded anymore -> bricked [17:21] bootloader sources are not public anyway, are they? [17:21] I don't thinkg so [17:22] that means we would not have anything to flash there anyway, so it does not really matter [17:22] zeros? ;) [17:22] point being, don't mess with the bootloaders just for fun.. [17:24] then I'll try to generate a sparse image < 600 Mo, that should allow me to use a 10Go filesystem, shouldn't it ? [17:24] yes [17:24] good [17:25] kulve: BTW could you drop some words about InvertX/InvertY that doesn't work with the touchscreen ? [17:27] sorry, I didn't try the new evdev driver but the different xorg mtev driver and for that those options did work [17:28] did you check the X.Org log if it says something about those options? [17:39] rbasak: That was supposed to be the point of the flash-kernel rewrite (or, one of the points), where the database of machine-specific settings was meant to eventually be a seperate package so others could source it. That last bit never happened. :/ [17:40] it will, at some point [17:40] rbasak: I have no fundamental issues with this happening (either a broken out DB package, or f-k having a foreign creation mode as you suggest), but I also have very little interest in being involved in f-k work at all. :P [17:42] all you want to skip is the actual writing to the device though [17:42] i think adding such a function should be rather trivial [17:46] OK, thanks all === albert is now known as Guest44624 [17:53] sfeole: how do you suggest we handle https://bugs.launchpad.net/ubuntu-nexus7/+bug/1082364 [17:53] Launchpad bug 1082364 in ubuntu-nexus7 "android debugger bridge cant be install on ubuntu on nexus 7" [Undecided,New] [17:54] cwayne: i did see that one, but put it aside for now, I think I may wait until monday when more of the staffers are back to work and question what to do about it [17:55] cwayne: in the meantime I'm moving some bugs back to a "New" status, such as this one... https://bugs.launchpad.net/ubuntu-nexus7/+bug/1080789 [17:55] Launchpad bug 1080789 in ubuntu-nexus7 "Corruption around mouse cursor when dragged, particularly around Dash, Indicators, window chrome" [Low,New] [17:55] cwayne: even though we have confirmed it, I don't think anyone is working it. If it is a upstream issue with NVidia then it should be handled accordingly [17:56] sfeole: no, leave them as confirmed [17:56] we don't want any new bugs [17:57] sfeole: Confirmed doesn't mean people are working on it, just that it's confirmed to be a bug. Moving back to new seems counter-intuitive. [18:00] ogra-cb: http://hwe.ubuntu.com/uds-r/nexus7/ these are the images people (eg. at XDA) should use, or are the 13.04 images ready for use? [18:00] cwayne: the email you forwarded to me this morning should adhere all bugs, not just bugs filed after the 21st. [18:01] sfeole: yes, but they dont say to move them to new [18:01] achiang: ^^ thoughts? [18:02] sfeole: it's been confirmed as a bug == marked confirmed [18:03] sfeole: i agree with the others, i do not think it should be new. i think that it should be confirmed. [18:04] achiang: ack [18:04] sfeole: for all tegra3 bugs, tag them with tegra3 and assign to me [18:04] achiang: will do [18:04] thanks [18:10] cwayne: https://bugs.launchpad.net/ubuntu-nexus7/+bug/1078696 [18:10] Launchpad bug 1078696 in ubuntu-nexus7 "gksu does not accept sudo password" [Low,Confirmed] [18:13] cwayne: Looks like you had the last word on the bug above , do you have any more insight on it? [18:13] i was about to run through the whole process myself of trying to reproduce , etc... [18:14] sfeole: all it needs is an assignee [18:14] if its confirmed, just follow victor's rules for assigning, that's all you'll need to do [18:15]