[00:32] <minimal> blackboxsw: ah ok, I was considering patching the Alpine package if it affected all renderers but now I know I'll just wait for 22.3.1
[15:42] <jbg> how can i completely disable the processing/merging of vendor data in cloud-init?
[15:42] <jbg> the docs say "Vendordata can be disabled by the user" but don't seem to mention *how* anywhere
[15:45] <blackboxsw> jbg: It's `vendor_data: false` in #cloud-config user-data provided during system launch I believe https://cloudinit.readthedocs.io/en/latest/topics/modules.html#scripts-vendor
[15:46] <blackboxsw> I'm double checking to be sure
[15:48] <blackboxsw> sorry I mean the folowing `vendor_data: {enabled: false}`
[15:50] <jbg> hm okay, does this mean if i am overriding the modules that run and don't include scripts-vendor, it should have the same effect?
[15:51] <jbg> because if so then the problem i thought was caused by vendor-data must be caused by something else, heh
[15:52] <jbg> i'll try it out anyway and see
[20:03] <beantaxi> Hello all ... what's the best way to parameterize my otherwise standard cloud-init.cfg with values like repo name, etc? I'm not seeing an idiomatic way to do it in instance data or other mechanism, so I wonder if I am expected to do that myself via a template engine, sed, etc. Thanks!


[00:00]  * wxl ponders the fact that "either/or" is ambiguous
 Hi, I installed Lubunru 1810 and I realized that if after installation we remove packages like about-lxqt and Qlipper through Discovery and then we do sudo apt-get update && sudo apt-get upgrade && sudo apt-get autoremove are removed only the packages libncursesw5 libtinfo5 lxqt-about-l10n but if we remove about-lxqt and qlipper th
[00:00] <moniker--> hmm didn't work with parenthetical value
[00:01] <wxl> moniker--: it certainly should. not sure what to say
[00:02] <wxl> @JyotiGomes one is a "software center" and one is a "package manager." The package manager acts exactly like other package managers. It would remove all the stuff, too.
[00:02] <moniker--> wxl is it xinput set-prop or set-props
[00:03] <wxl> moniker--: manpage says set-prop. my bad.
[00:03] <wxl> it's also list-props.
[00:03] <moniker--> ok i corrected that and got badaccess (attempt to access private resource denied)
[00:03] <wxl> i think that was the confusion, though it makes sense. you set one property at a time but you show all properties
[00:04] <moniker--> do i need sudo?
[00:04] <moniker--> sudo su
 @wxl [<wxl> @JyotiGomes one is a "software center" and one is a "package manager." The …], I thought this would happen if I chose the option to eliminate an application but not when it happened I chose the option to just remove ...
[00:04] <wxl> you shouldn't. i just set something on my mouse and didn't need it.
[00:05] <wxl> you could try though
[00:06] <wxl> @JyotiGomes you should consider Discover kind of "dumb." it doesn't have all the features, but instead is meant to be easy to use. if you're really trying to remove a package and all its dependencies that are otherwise not needed, you wouldn't want to use it.
[00:07] <moniker--> it was my bad i used code for "Tapping Enabled Default (429)" instead for "Tapping Enabled (427)"
[00:07] <moniker--> *428
[00:07] <wxl> see, still making mistakes XD
[00:08] <moniker--> i see now why you don't like tap to click
[00:08] <moniker--> it has different functionality in lubuntu
[00:08] <wxl> oh?
[00:09] <moniker--> or at least i think it's different
[00:09] <moniker--> no maybe i'm wrong, i was thinking that first tap to click should only focus window without clicking inside it
 @wxl [<wxl> @JyotiGomes one is a "software center" and one is a "package manager." The …], Does this mean that for the removal of applications that come with Lubuntu by default it is safe to use only discovery? But how safe is this removal? Is it okay to remove the libtinfo5 lxqt-about-l10n libncursesw5 packages after removing the
[00:12] <wxl> @JyotiGomes no. i'm saying that if you want to clean out everything as much as possible, DON'T use Discover. it's totally safe either way. autoremove won't remove things that you need for other things.
[00:13] <moniker--> natural scrolling is just opposite direction of normal scrolling so that when you slide with fingers upward on touchpad the screen scrolls up too instead of down which is normally the case because you are effectively shifting content up in that case
[00:14] <wxl> EW LIKE A MAC NO THANK YOU
[00:14]  * wxl curses it
[00:14] <moniker--> yeah doesn't seem very natural to me lol
[00:14] <wxl> i mean regardless of whether or not it makes logical sense, how long have we been doing it unnaturally???
 But after removing these about-lxqt and qlipper trough Moun and do a autoremove in terminal it were removed a lot of things that i used for other things and the entire Lubuntu desktop 😊
[00:15] <moniker--> so after i install lubuntu i just execute this command and it will remember?
[00:15] <wxl> it doesn't make sense that salmon swim upstream, but they do!!!!
[00:15] <wxl> @JyotiGomes you removed the index file for the lubuntu metapackage. that's different. you can't have parts of lubuntu and still have the metapackage. it would be incomplete.
 @wxl [<wxl> @JyotiGomes no. i'm saying that if you want to clean out everything as muc …], But after removing these about-lxqt and qlipper apps trough Moun and do a autoremove in terminal it were removed a lot of things that i used for other things and the entire Lubuntu desktop 😊
[00:16] <wxl> moniker--: no, that's where you'll need to add it to an autostart sort of thing
[00:16] <moniker--> alright, when i get there, thx for all the help so far
[00:17] <wxl> np
[00:17] <moniker--> btw is it possible to have taskbar thumbnail previews in linux like windows 10 does it?
[00:17] <moniker--> when you mouse over taskbar items
[00:17] <wxl> i know of nothing like that yet
[00:17] <wxl> whether or not it will be added is a question, too
[00:17] <moniker--> speaking just for lubuntu or in general on linux?
[00:17] <wxl> for lxqt-panel specifically
 @JyotiGomes why you want to remove those packages? Do you need the space?
 @wxl [<wxl> @JyotiGomes you removed the index file for the lubuntu metapackage. that's …], If i remove apps trough Discovery this will not implicate the remocion of the index file for the lubuntu metapackage as when doing this removal trough Moun?
[00:18] <wxl> and just keeping line with the lxqt goals of being light
[00:18] <wxl> but kubuntu certainly has it
[00:18] <moniker--> do you think KDE from ubuntu might have it and would KDE be much slower on this old laptop?
[00:18] <wxl> it will demand a little more out of your machine
[00:18] <moniker--> or kubuntu
[00:18] <moniker--> hmmm
[00:18] <wxl> at least i think it has it
[00:18] <moniker--> ok thx i might download and test it cost me nothing
[00:20] <wxl> btw preferences > lxqt settings > session settings > autostart
[00:20]  * wxl boots kubuntu vm
[00:21] <moniker--> and then add and type in command kk thx!
[00:21] <wxl> np
[00:22] <moniker--> i just read it can be done in xfce supposedly
[00:22] <moniker--> https://forum.xfce.org/viewtopic.php?id=11960
[00:22] <wxl> yeah i would expect it in kde. kind of shocked
[00:33] <moniker--> i've got around 30gb free space, but ill probably need some for XP, so how much you reckon is needed for lubuntu?
[00:33] <moniker--> is 15-20gb enough?
[00:37] <moniker--> wxl?
[00:41] <wxl> @JyotiGomes correct, because Discover does as little as possible
[00:41] <wxl> moniker--: sorry, work called.
[00:41] <moniker--> no probs
[00:41] <wxl> moniker--: i think that sounds good. you probably could get away with a minimum of 8gb but the more you have the better for you
[00:42] <moniker--> i just read there needs to be 3 partitions, is that correct? says one for OS at least 18gb then one for swap file and one for /home
[00:42] <moniker--> does installer create those automatically or do i need to manually create?
[00:42] <wxl> you can do a swap file which is standard for *buntu these days
[00:43] <wxl> it'll do it
 @wxl [<wxl> @JyotiGomes correct, because Discover does as little as possible], I'm going to ask a rather silly question: since I've already removed the about-lxqt and qlipper from Moun on several computers but have not yet used autoremove on the terminal (which would lead to the removal of the index file for the lubuntu metapackage
[00:43] <moniker--> i dont wanna accidentally delete windows xp
[00:44] <wxl> @JyotiGomes never tried but my guess is you should reinstall them in Muon, uninstall them in Discover
[00:44] <wxl> moniker--: you won't, but backup if you can!!!!
 @wxl [<wxl> @JyotiGomes never tried but my guess is you should reinstall them in Muon, …], Thank you. It's about ten school computers where I've done this removal through Moun and wanted to avoid having to reinstall Lubuntu all over again in all of them and do all the after-install tweeks again
 @wxl [<wxl> @JyotiGomes never tried but my guess is you should reinstall them in Muon, …], I see that even though you are in a dialogue with other people about other topics, you have found time to respond to my strange questions 😊 Thank you for your availability.
[01:02] <wxl> @JyotiGomes happy to help :)
[01:11] <moniker--> wxl this laptop im setting is for father of a friend to browse the net in firefox... is lubuntu set it and forget it regarding updates, is it automatic or not?
[01:14] <wxl> moniker--: you can make it be
[01:14] <moniker--> im reading now by default it is off, right?
[01:14] <moniker--> "Lubuntu has automatic updates turned off by default, as on slower CPU's / Low RAM machines it can cause the user to think the machine has 'locked up' / 'hung' as it performs that task. "
[01:15] <moniker--> if updates are set to be automatic what happens if you are running firefox and it wants to update it?
 @JyotiGomes why you need to remove those packages?
[01:16] <wxl> yep
[01:17] <wxl> moniker--: you can look at it this way: the binary that's running is in memory. however, you can change the binary on disk and not affect memory. so you can make an update and not affect the running app
[01:17] <moniker--> really? i don't think windows can do that
[01:17] <wxl> yeah well
[01:17] <wxl> windows sucks XD
[01:17] <moniker--> there must be tradeoff for that feature :P
[01:17] <wxl> it means you're not running the latest version
[01:18] <moniker--> i was thinking more along the lines of some bugs/crashes
[01:18] <wxl> whereas windows would kind of force that
[01:18] <wxl> nope
[01:18] <moniker--> depending how the application is coded
[01:18] <wxl> i mean this is true with the kernel even
[01:18] <wxl> in fact the kernel is the only software that actually requires a reboot to start using a new version of (unless you use live kernel updates)
[01:19] <moniker--> hopefully in future even that will be worked around so no reboot will be necessary
[01:19] <wxl> see above
[01:19] <moniker--> it's only a matter of engineering it i think
[01:19] <wxl> live kernel updates
[01:19] <wxl> it's just not a default thing
[01:20] <wxl> but neither is zfs and it's clearly superior (our installer doesn't support it yet sigh)
[01:20] <moniker--> do you know by chance why on this pentium m is needed to add forcepae attribute
 @HMollerCl [@JyotiGomes why you need to remove those packages?], The true? Qlipper is a bit annoying and I do not use it and the about-lxqt I think should not be on the main level of the menu, it's a bit like a self-promotion (despite all the merit of the developers)
[01:20] <wxl> because of the architecture of that chip
[01:20] <wxl> !pae
[01:20] <wxl> @JyotiGomes they're both easily removed from the menus
 @wxl [<wxl> @JyotiGomes they're both easily removed from the menus], Do you mean, change the place?
[01:22] <moniker--> i see so this pentium m has PAE capability but doesn't show PAE flag and that's why it has problems and OS needs to use forcepae
[01:22] <wxl> @JyotiGomes remove the .desktop files from /usr/share/applications and they don't show up in the menus
[01:22] <wxl> moniker--: something like that yes
 And you can remove autostart of qlipper
[01:23] <wxl> that too
 @wxl [<wxl> @JyotiGomes remove the .desktop files from /usr/share/applications and the …], You mean that if sometime in future i want to show the about lxqt i can just call the app by terminal?
[01:25] <moniker--> kubuntu apparently dropped 32bit support in 18.10
[01:25] <wxl> @JyotiGomes yes. the .desktop files are for the menu. they're just pointers to the actual binaries
[01:26] <wxl> yeah and we just dropped support for the next version :(
[01:26] <moniker--> which is next version
[01:26] <wxl> 19.04
[01:26] <wxl> in april
[01:26] <moniker--> is there LTS version of lubuntu
[01:26] <wxl> you'll be able to upgrade but you won't be able to grab an iso
 @wxl [<wxl> @JyotiGomes yes. the .desktop files are for the menu. they're just pointer …], Ok. I will reinstall them by Moun and keep them :-)
[01:26] <wxl> and when support runs outyou'll be kind of stuck
[01:27] <moniker--> but that's few years down the line no?
[01:27] <wxl> the .04s are the LTSes
[01:27] <wxl> yes
[01:27] <moniker--> so what you recommend then should i install 18.10 or 18.04
[01:27] <moniker--> lets
[01:27] <moniker--> lts
[01:27] <wxl> i'd do 18.10 personally. it's just nicer
[01:28] <moniker--> and via autoupdate it will go up to 19.04
[01:28] <moniker--> any previews of 19.04
 @HMollerCl [And you can remove autostart of qlipper], I will do that
[01:30] <moniker--> and last ubuntu 32 bit is 16.04.5?
 18.04 is for 32bits and lts
[01:33] <wxl[m]> Last 32 is 18.10
[01:33] <wxl[m]> There are daily images of 19.04
[02:22] <byter> Hi, I have a question about VPN on Lubuntu?
[02:26] <wxl[m]> byter feel free to ask
[05:12] <moniker--> wxm have you ever seen message at boot about "corrupted low memory" ?
[05:19] <moniker--> is there cpu profiling regarding frequency scaling in lubuntu?
 @tsimonq2 [It's one of the things I'll sit down and learn how to do, then implement it in S …], That means that who has Lubuntu 1810 installed will get this functionality through a simple update, correct?
[11:04] <moniker--> hmm lubuntu sometimes hangs on shutdown or reboot
[11:09] <moniker--> also installed lubuntu on hdd of laptop is so much slower to boot than livecd from usbkey :(
[11:09] <moniker--> like 2-3 times slower
[11:48] <guiverc> moniker--, some hdd's being slow can be signs of health issues; so I'd check your SMART health (on drive). eg. wdd green have long lives; and slow speed if drive errors are detected (to prevent errors they just slow as they 'correct' to avoid warranty-claims as warranty is not offered on speed, just continued function)
[11:59] <moniker--> guiverc it seems installer didn't create swap partition
[11:59] <moniker--> guiverc as i understand now swap partition is needed for hibernate to work?
[12:12] <guiverc> yes hibernate copies memory to swap (providing you have enough free swap to save memory). i always create my own partitions so aren't sure what swap is created by default (it varies possibly by version; later releases can create swap.file i believe)
[12:14] <moniker--> i shrank partition to create free space and in gparted created partition 2gb in size with file system linux-swap
 normal installation use swap files instead of partitions
[12:15] <moniker--> guiverc can you help me how do i activate it permanently so lubuntu uses swap partition
 Hibernation is highly unrecommended
[12:16] <moniker--> is there simple command to make lubuntu use the swap partition i just created?
 first, we must be surev you are not usig it
 in a terminal run: ... free -m
 an put the output here
[12:17] <moniker--> sec let me reboot into lubuntu
[12:17] <moniker--> i was in partedmagic.iso
 we also would need to see what the file /etc/fstab has
[12:20] <moniker--> so free -m says memory total is 1215 used 180 free 720 shared 25 buff/cache 314 available 859 and for swap all zeroes
[12:20] <moniker--> i dunno how you see this file /etc/fstab
[12:20] <moniker--> what is command?
 the easiest way is: ... cat /etc/fstab
 @moniker-- [<moniker--> so free -m says memory total is 1215 used 180 free 720 shared 25 buf …], so, its using swap file
[12:22] <moniker--> says UUID=<big number> / ext4 defai;ts - 1
[12:22] <moniker--> defaults*
 it says nothing about swap?
[12:23] <moniker--> says nothing about swap
 ok, you need to add a line there that tells the system where the swap is
 yo said you already had a swap partition right?
[12:24] <moniker--> ye i just created it in gparted 2gb with file system linux-swap
 you need to get the UUID of that partition
 I'm not sure hw to get it now
 we will have to look in internet
[12:25] <guiverc> thanks HMollerCl ,  try `sudo blkid |grep sda`  to get UUID of swap
 perfect
 here you can find the info on how to create the entry in fstab
 https://wiki.archlinux.org/index.php/Fstab
[12:26] <moniker--> guiverc i got uuid
[12:27] <moniker--> it's /dev/sda3
 Here is a fstab with swap partition: ... # <device>                                <dir> <type> <options> <dump> <fsck> ... UUID=CBB6-24F2                            /boot vfat   defaults  0      2 ... UUID=0a3407de-014b-458b-b5c1-848e92a327a3 /     ext4   defaults  0      1 ... UUID=b411dc99-f0a0-4c87-9e05-184977be8539 /home ext4
[12:27] <moniker--> sda1 is winxp sda2 is lubuntu and sda3 is swap
 last line is the swap partition
 which lubuntu version you have?
[12:29] <moniker--> 18.10
[12:29] <moniker--> i dunno what is last line
[12:29] <moniker--> everything looks mangled
[12:30] <moniker--> ok this is last line "UUID=f9fe0b69-a280-415d-a03a-a32752370dee none  swap   defaults  0      0"
[12:30] <moniker--> and i just replace UUID with my UUID right?
 ok, then run this to create a backup of fstab before editing: ... cp /etc/fstab /etc/fstab.old
[12:30] <moniker--> now how do i edit this fstab
 (cp =copy)
[12:31] <moniker--> cannot, seems to require sudo or something
 maybe you need sudo privileges so: ... sudo cp /etc/fstab /etc/fstab.old
[12:31] <moniker--> done
 now: ... lxqt-sudo featherpad /etc/fstab
 that will open featherpad (text editor) with sudo priviliges
 and you woul need to add a line at the end similar to: UUID=f9fe0b69-a280-415d-a03a-a32752370dee none  swap   defaults  0      0" ... but with the UUID of your swap partition
[12:33] <moniker--> it opened but also gave me this output in terminal "QStandardPaths: wrong ownership on runtime directory /run/user/1000, 1000 instead of 0
[12:33] <moniker--> "
[12:33] <moniker--> that's not a problem is it?
 don' worry
[12:34] <moniker--> ok
[12:34] <moniker--> do spaces matter?
[12:34] <moniker--> or do i use tab key or what
[12:35] <moniker--> how do i know how much spaces between words and numbers
 same as the line you have above in your file
[12:36] <moniker--> ok it's 14 spaces between / and swap and 4 spaces between swap and defaults
[12:36] <moniker--> ok done
[12:36] <moniker--> now i save and that's it?
 there is one step needed
[12:37] <moniker--> is that it? do i need to reboot?
[12:37] <moniker--> ok im listening
 you could, but we can do it w/o reboot I think
[12:37] <moniker--> what is the last step
[12:37] <moniker--> i have to go sorry, i need to hurry
 mount -a
 or_
 sudo mount -a
 done?
 after that, run again free -m
[12:41] <moniker--> after doing that it still says swap 0 0 0
[12:41] <moniker--> maybe reboot is needed?
 could be
 reboot
[12:41] <moniker--> ok gonna reboot fast, and thanks for all the help
[12:41] <moniker--> i need to go to give this laptop away
 after reboot, free -m.
[12:42] <moniker--> it's for a father of a friend to browse the net in firefox
 that will not ensure yu can hibrnate
[12:42] <moniker--> i will
[12:42] <moniker--> well it was worth a shot
 you will have to run:
[12:42] <moniker--> everything else seems to work, sleep works
 sudo systemctl hibernate
 @JyotiGomes [That means that who has Lubuntu 1810 installed will get this functionality throu …], No
 and see what comes out
[12:43] <moniker--> free -m now shows swap 2057
[12:44] <moniker--> nice thx for the help
[12:44] <moniker--> hibernate seems to work too
[12:44] <moniker--> thx gotta goooo
[12:44] <moniker--> luv ya
 np
[16:50] <moniker--> i wanna thank all that helped me here with lubuntu... very nice lightweight OS that surprised me how well out of the box it worked
[21:14] <AuroraAvenue> Hiya Saw this toot.
[21:14] <AuroraAvenue> https://mastodon.technology/@lubuntu/101433938726964974
[21:14] <AuroraAvenue> not all set up here - but what channel is the meeting at today ?
[21:14] <wxl> hey there
[21:14] <wxl> #lubuntu-devel
[21:14] <AuroraAvenue> k
[21:14] <wxl> it should be in that link
[22:21] <AuroraAvenue> https://twitter.com/ubuntu/status/1086025140973027329/photo/1
 @tsimonq2 [No], 😃
 Hello! A little doubt. When adding a new user (student) to Lubuntu 1810 I chose the name "student". Then I saw that it was better to have chosen another name. I can change the user name and even the user's home folder name. But is it also possible to change the name of the main group that this user belongs to?
[22:37] <wxl> @JyotiGoems yep it's all in the same place https://manual.lubuntu.me/3/3.2/3.2.15/users_and_groups.html
 Thanks
[22:41] <wxl> np
 @wxl [<wxl> @JyotiGoems yep it's all in the same place https://manual.lubuntu.me/3/3.2 …], I have seen that after we change the user name and group, we have to enter "sudo pcmanfm-qt" and also change the name of the home folder to match the new user name and group


[02:15] <brute-force> Hi everyone, i'm having an issue with an ubuntu app, may attach a screenshot of my issue?
[11:13] <ppisati> ogra_: FWIW, i sent the rename patch, if you can't work on flash-kernel i can give it a look
[11:14] <ppisati> ogra_: and here is a kernel with the new name
[11:14] <ppisati> ogra_: http://people.canonical.com/~ppisati/linux-image-3.8.0-13-multiarm_3.8.0-13.24~musb3_armhf.deb
[11:14] <ppisati> ogra_: omap3/4, imx6 and vexpress
[11:14] <ogra_> ppisati, right, the DBB structure needs some changes for this
[11:15] <ogra_> *DB
[11:15] <ogra_> yuo didnt by chance talk to debian about it ?
[11:15] <ppisati> ogra_: nope
[11:15] <ogra_> so that we dont have to carry our own patch for an incompatibel naming scheme ?
[11:15] <ogra_> hmm, k
[11:16] <ogra_> they are just implementing the same but still discuss the naming afaik
[11:16] <ogra_> would really have been good to coordinate on that
[11:16] <ogra_> since the f-k changes wont be small
[11:17] <ogra_> (thires neither ... but we will have to rip out their naming and replace it with ours on eery merge now)
[11:18] <ppisati> ogra_: i didn't look at the code, but isn't an s/omap/multiarm/ change?
[11:19] <ogra_> no, since you can use both
[11:19] <ogra_> theh DB needs an additional field that tells f-k that you can do that and the code needs to manage both types
[11:20] <ogra_> else upgrades wont work and third party vendor kernels wouldnt either
[11:21] <ogra_> (and especially for omap there is an endless amount of BSP and vendor kernels)
[11:21] <ppisati> ogra_: i really don't get it
[11:21] <ppisati> ogra_: i mean, we imported the new debian flash-kernel
[11:22] <ppisati> ogra_: that changed our habits and made impossible to install previous kernel
[11:22] <ogra_> yes, to minimize the delta with debian
[11:22] <ogra_> which is a bug
[11:22] <ogra_> you can blame me for not having gotten to it yet
[11:22] <ppisati> ogra_: no no
[11:22] <ogra_> yes, you can :)
[11:22] <ppisati> ogra_: it's just, we can't wait for debian for evrything
[11:22] <ogra_> i promised it ages ago and forgot about it
[11:23] <ogra_> we dont
[11:23] <ogra_> we usually patch stuff proactively ... but patches need to be able to flow back somehow, else we need to maintain the delsta
[11:23] <ppisati> ogra_: anyhow, if you can work on that ok
[11:23] <ogra_> i plan to ... today actually
[11:23] <ppisati> ogra_: else, i'll tackle it
[11:24] <ppisati> ogra_: don't want to step on your feet
[11:24] <ogra_> but it would have been good to coordinate the naming with debian in advance
[11:24] <ogra_> so we dont have to carry a huge patch that renames the world
[11:24] <ogra_> i think they are aiming for something like armmp
[11:25] <ogra_> lool, any comment ^^
[11:25] <marvin24> unfortunately, tegra will only support multiarch in 3.10 or so
[11:25]  * lool reads up
[11:26] <lool> ogra_: topic is installing old kernels or multiarm kernels?
[11:26] <ogra_> multiarm
[11:27] <ogra_> for older i'll just add a --force-version that overrides the check
[11:27] <ogra_> thats trivial
[11:27] <ogra_> for multiarm we'll need a new DB field and code rthat uses it i think
[11:28] <ogra_> MultiPlatformCapable=true ... or some such
[11:28] <ogra_> and then match against that in the code to allow -multiarm vs -$flavour if its available on disk
[11:29] <ogra_> lool, what bothers me is that we dont use a consitent naming with debian that would save us a delta
[11:31] <ogra_> marvin24, well, 3.10 isnt far :)
[12:14] <lool> ogra_: if it helps, we can split the dbs and change the rules with dpkg-vendor to have Debian and Ubuntu dbs
[12:14] <ogra_> we'll see, let me come up with some code
[12:14] <lool> ogra_: for multiarch, I'm not quite sure a new field is the way to go; you could just list multiarch as the kernel flavor for all hardware supported by this kernel
[12:15] <ogra_> k
[12:15] <lool> basically just listing multiarch in Kernel-Flavors might just work
[12:15] <ogra_> k
[12:15] <lool> s/multiarch/multiarm/g sorry
[12:15] <lool> these words are too close in my brain  :-)
[12:15] <ogra_> yup
[12:16] <lool> multiarm should be sheeva or something
[12:16] <ogra_> heh
[13:45] <ogra_> lool, ppisati, http://paste.ubuntu.com/5634079/
[13:45] <ogra_> for a quick way to skip the version check
[13:48] <ogra_> lool, so regarding your mail you seem to suggest to enforce -multiarm only i.e. so -omap kernels wouldnt work at all anymore ... i dont think i like that idea it makes using a BSP or vendor kernel thats not from mainline impossible ... i'd rather see us supporting both, the old flavour name and multiarm here ...
[14:11] <lool> ogra_: So the flash-kernel $version is just for backwards compat
[14:11] <lool> ogra_: But you could implement force-version in a simpler way now, keeping this compat aroun
[14:11] <ogra_> simpler than above ?
[14:12] <lool> ogra_: You would add a block just like for --machine, then skip the latest_version check if force_version is set; if force_version is set, just set kvers to it
[14:12]  * ogra_ found that fairly simple :)
[14:12] <lool> ogra_: Welll, simpler as in more readable
[14:12] <lool> it would be more lines
[14:12] <ogra_> yeah i did that first, but it adds extra vars and stuff
[14:12] <lool> that's fine
[14:12] <ogra_> k
[14:12] <ogra_> so about the other stuff
[14:13] <ogra_> a) we never remove kernels anywhere
[14:13] <ogra_> and i wouldnt see flash-kernel as a responsible tool to do that if we would
[14:13] <ogra_> b) we should go on supporting the old naming scheme for people rolling their own kernels
[14:14] <lool> a) -- yup, I think that's entirely orthogonal though
[14:14] <ogra_> c) i definitely think the packaging conflict/breaks/replaces stuff has to happen in the kernel package if needed
[14:14] <lool> c) -- yup
[14:14] <ogra_> and i would actually expect ppisati to already have all that stuff in the new packaging
[14:15] <lool> b) -- this should just keep working as it does now, unless they were using the same kernel flavor that we intend to drop
[14:15] <lool> there is actually another way to implement this which is completely different
[14:15] <lool> OMG I'm not sure I ought to mention this
[14:15] <lool> ogra_: Another entirely different pas is superseding Kernel-Flavors with Kernel-Configs
[14:15] <lool> this is quite different
[14:15] <ogra_> well, i would really just add a "MultiarmCapable" field to the DB
[14:16] <lool> uh
[14:16] <ogra_> and extend the flavour check a bit ... in a way that -multiarm is preferred if existing
[14:17] <ogra_> that way you can still support both
[14:17] <lool> I dont think that relates to the db, or then it's another d
[14:17] <lool> d
[14:17] <lool> db
[14:17] <ogra_> but need to make sure -multiarm is removed when you use your own play around kernel
[14:17] <lool> I'm all confused now
[14:18] <lool> the requirements in email seemed relatively clear to me: switch from -omap and others to -multiarm
[14:18] <lool> I think the plan is fair enough there
[14:18] <lool> Now I'm not quite sure what requirement we're discussing
[14:18] <ogra_> i want to keep the ability of being able to use -omap
[14:19] <ogra_> you seem to want that  "Kernel-Flavors: multiarm" replaces "Kernel-Flavors: omap"
[14:20] <ogra_> i would like to keep Kernel-Flavors: as is and add a new field that tells us "this machine can also use multiarm"
[14:20] <ogra_> so people rolling their own 3.2 kernel which cant be multiarm can still use -omap
[14:20] <ogra_> (as an example)
[14:23] <lool> ogra_: we could have some kind of priority in the database to support multiple cases, but it kind of strikes me as dangerous
[14:23] <lool> I'd rather folks add a local db of their own somewhere and have to maintain it
[14:24] <ogra_> why, -multiarm would always be preferred
[14:24] <lool> or we define how custom kernels are named (e.g. -custom) and that's it
[14:24] <lool> ogra_: I dont get it, do you want them to use -omap or -multiarm
[14:25] <ogra_> if there is no -multiarm binary in /boot we just fall back to "Kernel-Flavors:
[14:25] <lool> in the end we support this and that hardware, this is the kernel you're supposed to use, and that's it
[14:25] <ogra_> i want us to use -multiarm (which doesnt need a "Kernel-Flavors:" field at all anymore)
[14:25] <ogra_> and still levae the opportunity to people building from older or BSP branches to have -omap
[14:26] <ogra_> or -omap4
[14:26] <ogra_> or -armadaxp
[14:35] <ogra_> lool, oh, and looking at your mail ... "we have some dependencies in place which ensure that flash-kernel  requiring multiarm is installed immediately after -omap is replaced by  -multiarm (not before, not any later)" ... that cant work, nothing depends on flash-kernel anywhere
[14:35] <ogra_> iirc on your request back then
[14:37]  * ogra_ sighs ... that whole discussion shoudl have taken place several months ago ... and debian should have been heavily involved
[14:41] <ogra_> hmm, so for the transition and wrt depends, i guess ppisati could add a versioned dep on f-k to his transitional package, that will go away at some later point anyway
[14:41] <ogra_> through clever conflicts/breaks/replaces login
[14:42] <ogra_> *logic
[14:44] <ogra_> hmm, so lets see if that works at all ...
[14:44] <ogra_> ppisati, can you test with editing the db and just change the "Kernel-Flavors:" field in your omap entry ?
[14:45] <ogra_> theoretically that should just make it work
[14:46] <ogra_> (practically i fear that 1.2.3-omap is simply bigger than 1.2.3-multiarm ... which triggets the kver issue)
[14:46] <ppisati> flag@flag-desktop:/usr/share/flash-kernel$ grep Kernel-Flavors db/all.db  | grep omap
[14:46] <ppisati> flag@flag-desktop:/usr/share/flash-kernel$
[14:47] <ogra_> err
[14:48] <ppisati> flash-kernel 3.0~rc.4ubuntu29
[14:48] <ogra_> yeah i have the source here
[14:48]  * ogra_ is baffled
[14:48] <ogra_> there is actually no "Kernel-Flavors:" in the DB
[14:48] <ogra_> so mind adding it for a test ?
[14:49] <ppisati> ogra_: there's actually
[14:49] <ppisati> ogra_: but there's no Kernel-Flavors in it
[14:49] <ogra_> for omap/omap4 ?
[14:49] <ppisati> yes
[14:49] <ppisati> Machine: OMAP3 Beagle Board
[14:49] <ppisati> etcetc
[14:49] <ppisati> and below omap4
[14:50] <ogra_> doesnt have a Kernel-Flavors: line here
[14:50] <lool> ogra_: Of course it can work, you Break flash-kernel << version-that-works
[14:50] <ogra_> lool, from what ?
[14:50] <ogra_> lool, nothing depends on f-k
[14:50] <lool> from the kernel package
[14:50] <lool> this wouldn't be a Depends but a Breaks
[14:50] <ogra_> yeah thats what i mean, but from the transitional package
[14:51] <ogra_> which will vanish anyway at some point
[14:51] <lool> Either from the new binary packages or from the meta pulling the right stuff
[14:51] <ogra_> why not from the transitional one ?
[14:51] <ogra_> ppisati, so whats in the Kernel-Flavors: line you see there for omap/omap4 ?
[14:51] <lool> I don't know which one you mean
[14:52] <lool> anyway, from some kernel package that ultimately tries to pull -multiarm
[14:52] <ogra_>  "we have some dependencies in place which ensure that flash-kernel  requiring multiarm is installed immediately after -omap is replaced by  -multiarm (not before, not any later)"
[14:52] <ogra_> from your mail
[14:52] <ppisati> ogra_: no no, there's no Kernel-Flavors in those omap3/4 entries
[14:52] <ogra_> "we have some transitional package which pulls in -multiarm when you  had e.g. -omap installed"
[14:52] <ppisati> ogra_: ok, i got it
[14:52] <ogra_> ppisati, ah
[14:52] <ppisati> ogra_: i'll add an entry
[14:53] <ogra_> ppisati, so please add one with multiarm
[14:53] <ogra_> then try again, that should make it not fall over in the kver check
[14:53] <ogra_> though looking at the code the version check runs before the flavour check
[14:54] <ogra_> me guesses that needs to move up
[14:55] <ppisati> ogra_: ok
[14:55] <ppisati> ogra_: i guess '3.8.0-13-multiarm' is lexically inferior to '3.8.0-10-omap'
[14:55] <ppisati> ogra_: that's why it fails
[14:56] <ppisati> ogra_: that's the only reason why it fails
[14:56] <ppisati> ogra_: let me do some more testing
[14:56] <ogra_> well, i still dont get how it gets its flavour at all
[14:56] <ppisati> ogra_: i don't know, it works, don't touch it
[14:56] <ppisati> ogra_: ah, and it works on imx6 too!
[14:56] <ogra_> yeah, it worked in the past by a matter of luck and cosmic rays :)
[14:57]  * ppisati loves cosmic rays
[14:57] <ogra_> hehe
[14:57] <ppisati> let me build an abi bumper kernel
[14:57] <ppisati> *bumped
[14:57] <ogra_> that wont make m larger than o
[14:58] <ppisati> ogra_: 3.8.0-13-omap vs 3.8.0-14-multiarm?
[14:58] <ogra_> the check logic is pretty screwed up due to the ordering
[14:58] <ogra_> the flavour check actually uses the version ... so the version check comes first all the time
[14:59] <ogra_> hmm, abi bump might work, not sure
[14:59] <ogra_> just cp the binary around ;)
[14:59] <ppisati> that's what i'm doing
[14:59] <ogra_> no need to build
[15:00] <ppisati> :)
[15:00] <ppisati> watch out:
[15:00] <ppisati> flag@flag-desktop:~$ sudo flash-kernel
[15:00] <ppisati> flash-kernel: installing version 3.8.0-14-multiarm
[15:00] <ppisati> Generating kernel u-boot image... done.
[15:00] <ppisati> Taking backup of uImage.
[15:00] <ppisati> Installing new uImage.
[15:00] <ppisati> Generating initramfs u-boot image... done.
[15:00] <ogra_> haha
[15:00] <ppisati> Taking backup of uInitrd.
[15:00] <ppisati> Installing new uInitrd.
[15:00] <ppisati> Taking backup of preEnv.txt.
[15:00] <doomlord> Does ubuntu-arm have a 'virtual mouse' when running on a tablet ( i know its not as good as dedicated touch ui)
[15:00] <ppisati> Installing new preEnv.txt.
[15:00] <ppisati> Taking backup of uEnv.txt.
[15:01] <ppisati> Installing new uEnv.txt.
[15:01] <ppisati> ABI bump FOR THE WIN! :)
[15:01] <ogra_> heh, yeah
[15:01] <ogra_> though i'm still confused about the missing flavour entry in the db
[15:02] <ogra_> but at least it saves us also from having that dependency stuff
[15:02] <ppisati> so, nothing else userspace wise?
[15:03] <ppisati> ogra_: ^
[15:03] <ppisati> lool: ^
[15:03] <ogra_> well, i'll add your --force-version now :)
[15:03] <ogra_> but nothing for you to do apart from making sure your version is high enough
[15:04] <ogra_> and indeed the proper debian/control entires to replace -omap stuff and do a clean transition as lool described in his mail
[15:04] <ogra_> (in your kernel package)
[15:04] <ppisati> ogra_: i think i did all the stuff in debian/control
[15:04]  * ppisati goes to re-read the email
[15:04] <ogra_> iirc breaks/replaces/provides
[15:05] <ogra_> for the former versions of the kernels ... (omap, armadaxp ? ... do we have omap4 in there yet ? )
[15:08] <ppisati> * we have some transitional package which pulls in -multiarm when you had e.g. -omap installed
[15:09] <ogra_> yeah
[15:09] <ppisati> isn't enough to point meta to the new -multiarm kernel?
[15:09] <ogra_> well you want to replace meta too ...
[15:09] <ogra_> currently linux-omap is installed
[15:10] <ppisati> ogra_: right
[15:10] <ogra_> and you want that to become linux or linux-multiarm
[15:10] <ogra_> so if i dist upgrade there must be an empty package called linux-omap that makes sure the new nly named one is pulled in
[15:11] <ppisati> right
[15:11] <ogra_> so either linux-omap vanishes from the archive and your new meta provides linux-omap (and all other flavours it replaces) or you have a transitional package
[15:13] <ogra_> else apt wont upgrade your kernel ...
[15:16] <ppisati> ogra_: ok, i'll let someone with more debian packaging knowledge than me handle that
[15:16] <ogra_> ok
[15:16] <ogra_> the abi bump happens anyway if i understood right ?
[15:16] <ppisati> ogra_: i'll ask to bump
[15:17] <ppisati> ogra_: but yes
[15:17] <ogra_> great, i'll add the --force for you :)
[15:17] <ogra_> so we can finally close that old bug
[15:31] <ogra_> ppisati, https://www.svtronics.com/index.php?route=product/product&product_id=33 ... the artist formerly known as "panda"
[15:33] <infinity> ppisati: Dude, "multiarm"?  What?
[15:33] <ppisati> ogra_: it's real! :) can't believe it! :)
[15:33] <ppisati> infinity: arm multiplatform
[15:34] <infinity> ppisati: I know what it means, I was asking who decided on that ridiculous name for the flavour?
[15:34] <ppisati> infinity: me, thanks
[15:34] <infinity> ppisati: We all agreed to have a -generic kernel ages ago.
[15:34] <ppisati> infinity: did we?
[15:34] <infinity> We did.  Was in several kernel team specs.
[15:35] <infinity> Well, generic and generic-pae (or generic-nonpae and generic, we hadn't stopped bikeshedding)
[15:35] <infinity> Since LPAE on A15 needs a -pae kernel.
[15:35] <ppisati> infinity: we can call it generic
[15:35] <ppisati> infinity: i don't have any atatchment to the flavour name
[15:36] <infinity> Kay.  Sorry for the strong reaction. :P
[15:36] <infinity> But yeah, we should just have generic and be done with it.
[15:37] <infinity> ppisati: As for the meta business, we'll do transitional metas.  Just hard rename omap to generic, don't try any silly provides.
[15:37] <infinity> ppisati: We have precedence for this with server->generic and generic-pae->generic, etc.
[15:38] <ogra_> as long as do-release-upgrade works ...
[15:38] <ogra_> which shurely all of our arm users use all the time :)
[15:38] <infinity> ogra_: It'll work fine, like I said, it'll be the same migration path as x86 kernels in the past.
[15:39] <ogra_> k
[15:39] <ogra_> bah, who always uploads these chromium ftbs to the ppa
[15:39] <infinity> ogra_: As for "does -generic support omap4", the answer is "yes", but we won't swap the metas around to force that upgrade, since we want PVR to keep working for people.
[15:39] <infinity> So, omap4/raring will still use the quantal 3.5.0 kernel.
[15:39] <ogra_> well... i wouldnt mind -generic on server
[15:39] <ogra_> but that gets to complex
[15:40] <ogra_> i suppose
[15:40] <infinity> Not worth the effort, really.
[15:40] <ogra_> yeah
[15:40] <infinity> And not guaranteed to be an upgrade. :P
[15:40] <ogra_> heh
[15:41] <infinity> Anyhow, the 3.5.0 Q kernel will be supported longer than R is, so this all magically works out.
[15:41] <ogra_> will be ?
[15:41] <ogra_> won't be you mean
[15:41] <infinity> Yay for reduced lifecycles having serendipitous side effects.
[15:41] <infinity> Will be.
[15:41] <infinity> Q is 18mo, R is 9.
[15:41] <qengho> ogra_: which ppa?
[15:41] <ogra_> oh, right
[15:42] <ogra_> qengho, canonical-arm-dev :) i'm not moaning about the ppa ... i'm moaning about it failing :P
[15:42] <qengho> ogra_: Ah, right.  Speaking of, can you add me to that team?
[15:42] <qengho> ~cmiller
[15:42] <ogra_> there should be a rule that every 100 uploads one will magically build :)
[15:43] <qengho> Well, if we're just legislating reality to our liking, I vote every one builds, without bugs.
[15:43] <ogra_> qengho, done
[15:43] <qengho> Thx.
[15:50] <suihkulokki> ogra_: better late than never, if you can mail debian-arm a summary of how you are going multiplatform, it would be nice
[15:53] <ogra_> suihkulokki, yep, planning to
[16:07] <infinity> ogra_: Where is this mail thread?
[16:07] <infinity> ogra_: Almost everything I'm seeing in backscroll is wrong.
[16:07] <ogra_> debian-arm
[16:07] <infinity> ogra_: There's no need for breaks/replaces/provides, or any of that.
[16:07] <ogra_> o which one do you mean
[16:08] <infinity> ogra_: I mean the one you refer to involving you, Loic, and Paolo?
[16:08] <ogra_> well, its all moot anyway
[16:08] <ogra_> so just ignore
[16:09] <infinity> It is? :P
[16:09] <ogra_> the whole discussion was based on the assumption that we have the flavour in the DB ... which we dont ... the issue was a simple versioning mistmatch
[16:09] <ogra_> which the abi bump fixes
[16:09] <infinity> Right.
[16:10] <infinity> Just hoping no one took the rest to heart.
[16:10] <ogra_> but i guess ppisati wouldnt mind if you give him a hand with the debian/control changes
[16:10] <infinity> ppisati: The only debian/control* changes required are s/omap/generic/ and you're done. :)
[16:11] <wookey> hmm /me never notices debian-arm anymore as it still goes to my aleph1 address which ends up on different box due to mail server mysteries
[16:11] <infinity> ppisati: (Assuming an ABI bump to cover package conflicts)
[16:11] <ppisati> infinity: yep
[16:11] <wookey> but I am interested in single zimage kernel packaging as it looks like I'll be miugged into making it work for linaro stuff
[16:12] <infinity> I think I already promised that I'd fix d-i for it in both Debian and Ubuntu.
[16:12] <ogra_> well, debian seemingly will call it armmp
[16:12] <infinity> I must have been drinking at the time.
[16:12] <wookey> better go and read thread I suppose. who is ppisati
[16:12] <ogra_> you will likelly endu up with linux-arm64-armmp over there at some point :)
[16:13] <infinity> ogra_: arm64 shouldn't need such a designation, it should be MP from the start.
[16:13] <ogra_> wookey, ppisati is an italian who missed the pope election and thus still works for us in the kernel team on our arm kernels
[16:13] <infinity> ogra_: But yes, it would make more sense if Debian went with what they do on other arches and just called it, say, -armv7 or -arm32 or something.
[16:14] <infinity> wookey: You may have more influence over silly naming in Debian than I would, if you have a better option than armmp. :P
[16:14] <ppisati> ogra_: next time that role will be mine... i swear...
[16:14] <infinity> Debian kernel flavours are a mess anyway.
[16:14] <ppisati> "Scream for me Vaticaaaaaaannnn!!!!"
 Whatever looks good to an unfortunate punter picking from a list is probably good
[16:16] <infinity> Since it won't have the same name as Ubuntu's similar flavour.
[16:17] <wookey> we could try and have the same name if there no good reason not to
[16:17] <infinity> wookey: The good reason is consistency. :P
[16:17] <infinity> wookey: We have -generic on i386 and amd64 already.
[16:17] <wookey> I thought there was a plan to make the kernel packaging less gratuitously differrent
[16:17] <infinity> wookey: Something gratuitously different on ARM is silly.
[16:18] <infinity> wookey: The kernel packaging ain't converging any time soon.  There may be some thought sharing or even some cherry-picking, eventually, but they're not going to converge.
[16:18] <infinity> (Not unless Debian adopts our naming scheme, cause we're sure not adopting theirs)
[16:18] <infinity> That statement needs a "nyah nyah" on the end of it, but you get the idea.
[16:18] <wookey> the naming and the packaging are probably fairly independent
[16:18] <infinity> True.
[16:19] <infinity> I know our kernel team just ate a DD who's going through debian* and picking it apart.
[16:19] <infinity> But I don't think the goal was convergence.  Just tidying.
[16:19] <wookey> separating the tools seems like a good thing to copy from debian for example
[16:19] <wookey> it would remove half the build-deps
[16:19] <infinity> Honestly, with our kernels being so wildly different in many ways, I'm not sure convergence matters.
[16:20] <wookey> except for people like me who have to hack both
[16:20] <infinity> Breaking out tools would be good, and it's our radar already.
[16:20] <infinity> s/our/on our/
[16:20] <infinity> Realistically, you shouldn't have to touch both much more than you already have.
[16:20] <ppisati> ok, bt there's already a debian.master/control.d/vars.generic
[16:21] <infinity> And it's pointlessly x86-specific.  Fail.
[16:21] <infinity> (It's also wrong)
[16:22] <wookey> there cross fixes, tools fixes, bootstrap fixes, multiarch fixes so far and they are mostly not transferrable due to radically different packaging, which is annoying.
[16:22] <infinity> wookey: Sure, but you've done those fixes, convergence now doesn't get you anything.
[16:22] <wookey> next there will probably be a pile of single zimage fixes
[16:23] <wookey> they aren;t all upstream yet so not really 'done'
[16:23] <wookey> you just like arguing
[16:23] <infinity> Well, yes.  But in this case, convergence is really, really hard.
[16:23]  * wookey goes to fix kernel build.
[16:24] <infinity> So, you're asking people to do a ton of work that they don't actually have to. :P
[16:24] <ogra_> wookey, nahh, he doesnt, hs is a https://lh6.googleusercontent.com/-RGqGhbZCxmI/UUraE5SMbGI/AAAAAAAABWE/IRwgZvae-5c/s707/smooth_canadian.jpg
[16:24] <ogra_> s/hs/he/
[16:25] <ogra_> canadians dont argue :)
[16:25] <wookey> the likeness is extraordinary
[16:25] <ppisati> section_image="universe/base"
[16:25] <ppisati> and
[16:25] <ogra_> (like germans arent srcastic)
[16:25] <ppisati> do_debug="Yes"
[16:25] <ppisati> are missing
[16:25] <ppisati> will the world crumble?
[16:26] <infinity> ppisati: Hrm?
[16:26] <wookey> if someone is fettling kernels can they put https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1105251 in please
[16:26] <ubot2> Launchpad bug 1105251 in linux "Fix cross- linux-tools build" [Medium,In progress]
[16:26] <ppisati> *grumble
[16:26] <infinity> ppisati: That section/image was a blatant lie, since omap was in main.
[16:26] <wookey> I've just had to move it all forward to 3.9
[16:27] <infinity> ppisati: However, the bootloaders var is much more troublesome.
[16:27] <ppisati> infinity: becase it'll put a dependency on all those packages, isn't it?
[16:28] <infinity> ppisati: Well, it could be fixable with [arch] restrictions.
[16:28] <infinity> ppisati: Since that's ending up in a control stub, which then gets parsed by dpkg-gencontrol.
[16:28] <ppisati> infinity: bootloader="grub-pc | grub-efi-amd64 | grub-efi-ia32 | grub | lilo (>= 19.1) | [armhf]flash-kernel" ?
[16:28] <infinity> ppisati: So, if all the current ones get [i386 amd64 x32] on them, and then you add "flash-kernel [armhf arm64]"
[16:29] <ppisati> bootloader="grub-pc | grub-efi-amd64 | grub-efi-ia32 | grub | lilo (>= 19.1) | flash-kernel [armhf arm64]"
[16:29] <infinity> You need to arch-restrict all the x86 ones too.
[16:29] <infinity> Or your arm builds will get deps on all of that.
[16:29] <ppisati> infinity: ok
[16:30] <infinity> (Some day, we'll want grub on arm anyway, but that day isn't today)
[16:30] <ppisati> bootloader="grub-pc [i386 amd64 x32] | grub-efi-amd64 [i386 amd64 x32] | grub-efi-ia32 [i386 amd64 x32] | grub [i386 amd64 x32] | lilo (>= 19.1) [i386 amd64 x32] | flash-kernel [armhf arm64]"
[16:30] <infinity> ppisati: Anyhow, it's a bit hard to sort out how this will all parse out through the build system, so do a quick smoketest on both x86 and armhf and see what the actual deps on the .deb end up being.
[16:31] <ppisati> infinity: i'll do
[16:31] <ppisati> infinity: and, about the provides=''
[16:31] <infinity> ppisati: That seems reasonable.  (Probably worth rewriting somehow so that can be less messy, but it's a bit of a "who cares", if this works)
[16:31] <ppisati> infinity: i think those are wrong for armhf too
[16:31] <ppisati> provides="kvm-api-4, redhat-cluster-modules, ivtv-modules"
[16:31] <infinity> ppisati: We surely build the same modules on armhf as x86.  If not, we should.
[16:31] <infinity> ppisati: So, the only lie there is kvm-api-4.
[16:31] <infinity> ppisati: Which kinda doesn't matter.
[16:32] <ppisati> ok, lemme try to pt it tgether and do a compile
[16:32] <infinity> ppisati: (And will stop being a lie with A15s)
[16:32] <infinity> Well, once the kvm/arm code lands upstream.  They've not been as awesome as the Xen guys. :P
[16:33] <ogra_> erm, where does that flash-kernel dep come from ?
[16:33] <ogra_> we never had kernels depend on f-k
[16:33] <ogra_> or did i miss omething
[16:33] <ogra_> s
[16:42]  * ppisati goes to eat an apple
[16:42] <infinity> ogra_: https://launchpad.net/ubuntu/raring/armhf/linux-image-3.8.0-13-omap/3.8.0-13.23
[16:43] <infinity> ogra_: Sure looks like it recommends flash-kernel currently.
[16:43] <ogra_> hmm, i thought we were denied doing that
[16:43]  * ogra_ remembers a heated discussion a few years ago when he wanted it like that for chroots
[16:44] <infinity> omap4 does as well.
[16:46] <ogra_> well, good then
[17:29]  * ogra_ sighs about his discussion in -desktop ... so debconf is dead ... since systemd uses "he POSIX way" of writing timezone data directly to /etc/localtime
[17:29] <ogra_> s/he/the/
[18:06] <ppisati> ok so
[18:06] <ppisati> dpkg -i works
[18:07] <ppisati> but flash-kernel is not aautomatically called
[18:07] <ppisati> what shall i check?
[18:07] <ppisati> infinity: ^
[18:08] <infinity> Erm, was it called with the omap kernel?
[18:08] <infinity> If so, nothing should have changed.
[18:09] <infinity> flash-kernel should have poop in /etc/kernel/postinst.d/ that triggers.
[18:10] <ppisati> lemme se if it's called with -omap
[18:12] <ppisati> flash-kernel: deferring update (trigger activated)
[18:12] <ppisati> when does it get called?
[18:15] <infinity> ppisati: It's called from /etc/kernel/postinst.d/, like I said.
[18:15] <ppisati> infinity: actually it's not called
[18:15] <infinity> ppisati: Which is called from the kernel postinst.  Which shouldn't have changed at all.
[18:15] <ppisati> infinity: flash-kernel: deferring update (trigger activated)
[18:15] <ppisati> infinity: deferred to when?
[18:15] <ppisati> infinity: when i type 'reboot'? don't think so
[18:15] <infinity> Deferred to when the dpkg run is done, in theory.
[18:16] <infinity> The trigger could be broken. :P
[18:16] <ppisati> infinity: ah k
[18:16] <ppisati> infinity: that makes more sense
[18:17] <ppisati> infinity: anyhow, same behaviour as with omap
[18:17] <infinity> Kay.  So, if anything's wrong, it's a flash-kernel bug, that's fine.
[18:17] <ppisati> infinity: lol
[18:17] <infinity> Did you do a build on both armhf and i386?
[18:18] <ppisati> infinity: yep
[18:18] <infinity> And if so, did you check the Recommends for each?
[18:18] <infinity> "dpkg-deb -I foo.deb | grep ^Recommends"
[18:18] <ppisati> infinity: lemme see
[18:19] <ppisati> ppisati@tangerine:~$ dpkg-deb -I linux-image-3.8.0-14-generic_3.8.0-14.24_amd64.deb | grep ^Recommends
[18:19] <ppisati> ppisati@tangerine:~$ dpkg-deb -I linux-image-3.8.0-14-generic_3.8.0-14.24_armhf.deb | grep ^Recommends
[18:20] <infinity> That might need a space. :P
[18:20] <infinity> "dpkg-deb -I foo.deb | grep '^ Recommends'"
[18:21] <ppisati> ppisati@tangerine:~$ dpkg-deb -I linux-image-3.8.0-14-generic_3.8.0-14.24_armhf.deb | grep "^ Recommends" Recommends: flash-kernel
[18:21] <ppisati> ppisati@tangerine:~$ dpkg-deb -I linux-image-3.8.0-14-generic_3.8.0-14.24_amd64.deb | grep "^ Recommends" Recommends: grub-pc | grub-efi-amd64 | grub-efi-ia32 | grub | lilo (>= 19.1)
[18:21] <ppisati> looks good
[18:21] <infinity> Shiny.
[19:35] <xnox> nice
[19:49] <ogra_> nephew
[20:17] <mjrosenb> is it expected that I can have libexpat1-dev:armel and libexpat1-dev:amd64 installed at the same time?
[20:18]  * Snark would say it's the point of multiarch
[20:18] <ogra_> thats the purpose of multiarch, yes
[20:29] <pizzacoca> hi guys, may someone have time to help I ve got a pb on my N7
[20:30] <pizzacoca> ?
[20:31] <ogra_> what is it ?
[20:34] <pizzacoca> I made the install following
[20:34] <pizzacoca> https://wiki.ubuntu.com/Nexus7/Installation#Troubleshooting
[20:34] <pizzacoca> but on boot there was lots of cmd lines saying unable to write blabla filesystem readonly
[20:34] <pizzacoca> https://wiki.ubuntu.com/Nexus7/Installation#Troubleshooting_the_Install
[20:35] <pizzacoca> I wait until cellbatt goes down nothing happened, only scroll of theses lines
[20:39] <pizzacoca> I just tried to boot it again it is still telling blabla readonly filesystem blabla
[20:42] <pizzacoca> Is that's meaning my first install  went wrong ?
[20:42] <pizzacoca> It took a long time during the
[20:42] <pizzacoca> $ fastboot flash userdata raring-preinstalled-desktop-armhf+nexus7.img command
[21:01] <ogra_> pizzacoca, yes, that means somethign went wrong
[21:01] <ogra_> check the md5sum of the img file
[21:04] <pizzacoca> ok, so I'll try again the install ... another thing, not really about ubuntu install : wen I listen very close to my N7 I can hear some sound from it (like the hp's always buzzing) knowed issue on N7 ?
[21:15] <ogra_> nope
[21:25] <pizzacoca> thanks ogra, I'll see that
[23:04] <ogra_> bug 1132439
[23:04] <ubot2> Launchpad bug 1132439 in touch-preview-images "Android and iOS have majority of the phone market share" [Critical,Confirmed] https://launchpad.net/bugs/1132439
[23:09] <darkfader> lol
[23:11] <darkfader> this is so funny, because you can't close-wontfix without becoming a joke


[03:24] <Noskcaj> emacsen, What do you mean?
[03:25] <Noskcaj> We'll start the blueprints for 15.10 shortly, but most of the plan is just package 3.16, then see if we have time to package 3.18.
[05:57] <mgedmin> 14.10 -> 15.04 was a very smooth upgrade, congratulations to you all!
[06:20] <mgedmin> gnome 3.16, here I come!
[06:21] <mgedmin> hmm
[06:21] <mgedmin> Unpacking adwaita-icon-theme-full (3.16.0-0ubuntu1~vivid1) over (3.14.0-2ubuntu8) ...
[06:21] <mgedmin> dpkg: error processing archive /var/cache/apt/archives/adwaita-icon-theme-full_3.16.0-0ubuntu1~vivid1_all.deb (--unpack):
[06:21] <mgedmin>  trying to overwrite '/usr/share/icons/Adwaita/32x32/actions/edit-delete.png', which is also in package adwaita-icon-theme 3.14.0-2ubuntu8
[06:22] <mgedmin> yes, I know to retry; but it'd be nice if someone uploaded an adwaita-icon-theme-full with the right Conflicts: adwaita-icon-theme << 3.16.0
[06:24] <Noskcaj> mgedmin, Without the internet to properly check, my guess is there are extra ubuntu changes we need to port to 3.16
[06:24] <mgedmin> I assumed the file just got moved from one package to the other
[06:24] <mgedmin> so when you unpack them in the wrong order, you get a conflict
[06:25] <mgedmin> repeating the apt-get dist-upgrade worked fine
[06:25] <Noskcaj> I might have time to fix over the weekend, but hopefully ricotz will beat me to it
[06:25] <mgedmin> (because adwaita-icon-theme was already 3.16.0 at that point)
[06:28] <Noskcaj> Just checked, we just need to merge in 3.14.0-2ubuntu8's changes
[06:39] <ricotz> Noskcaj, will take a look
[06:45] <darkxst> yeh they kept moving files around within the packagaing!
[06:57] <mgedmin> huh, horizontal mouse wheel scroll direction seems reversed
[07:03] <mgedmin> it will take me a while to get used to the new theme in 3.16
[07:05] <ricotz> https://bugzilla.gnome.org/show_bug.cgi?id=737175
[07:06] <mgedmin> I see: fixed upstream, but not released yet
[07:09] <mgedmin> interesting: I seem to have two gdms running, one on tty2 (where I'm logged in) and one on tty7 (where I see what looks like a lock screen)
[07:18] <mgedmin> oh, right, the mediakeys bug
[07:19] <mgedmin> what's the status on that?
[07:19] <mgedmin> because it's not fun when most shortcut keys don't work (and by most I mean PrintScreen, Ctrl-Alt-T, volume, lock screen)
[07:34] <mgedmin> haha, gnome-control-center thinks it's still ubuntu 14.10
[07:34] <mgedmin> is the version string baked into the logo image?
[07:49] <Noskcaj> mgedmin, Is that a ubuntu version or ppa version of g-c-c?
[07:50] <mgedmin> ppa, I guess
[07:50] <mgedmin> yes: 1:3.16.1-0ubuntu1~vivid1
[07:50] <mgedmin> ubuntu version has the ubuntu logo; this one has the gnome logo
[07:51] <mgedmin> (I haven't actually checked g-c-c after upgrading to vivid and before adding the gnome3-staging ppa)
[07:51] <mgedmin> as for https://bugs.launchpad.net/ubuntu-gnome/+bug/1427877: vt switch triggers this bug for me
[07:56] <darkxst> mgedmin, I fixed the g-c-c string in vivid
[07:56] <darkxst> probably never merged it to the packages in staging
[07:57] <darkxst> mgedmin, can you comment on the upstream bug with that info (for media key bug)
[07:57] <mgedmin> ah, didn't notice the upstream bug link!
[07:58] <darkxst> mgedmin, btw, the g-c-c logo is autogenerated at build time, but uses a static string, to generate the image
[08:03] <mgedmin> yeah, gresource extract /usr/bin/gnome-control-center.real /org/gnome/control-center/info/UbuntuLogo.png > /tmp/logo.png gives me the image with "ubuntu 14.10" baked in
[08:03] <darkxst> mgedmin, btw, with gdm waylandised, I think the gdm greeter lives on vt7
[08:04] <mgedmin> oh, is the greeter always running now?
[08:04] <mgedmin> my session is on vt2, gdm greeter is on vt7
[08:05] <mgedmin> vt1, vt3, vt4, vt5, vt6 are text consoles
[08:05] <darkxst> yeh I think that is right, gdm now runs under wayland, so guess it needs to stay open
[08:06] <mgedmin> I like how smooth the vt switching is
[08:06] <darkxst> I don't know why vt2, thats probably a fedora thing
[08:06] <mgedmin> heh, the wifi icon in the greeter is a solid white square
[08:06] <darkxst> not seen that here
[08:07] <mgedmin> is there a way to take screenshots of the greeter session?
[08:08] <darkxst> camera?
[08:09] <darkxst> pretty sure screenshots are disabled there
[08:10] <darkxst> otherwise I suppose you could try run gnome-screenshot as gdm user
[08:11] <mgedmin> http://i.imgur.com/NpdWZgw.jpg
[08:12] <mgedmin> huh, I now have 6 copies of gnome-settings-daemon running
[08:13] <mgedmin> each time I do the workaround, I get a new one
[08:17] <darkxst> mgedmin, I would expect 2, one for gdm and one for your session
[08:18] <mgedmin> the number increases every time I run gnome-settings-daemon -r when media keys aren't working
[08:18] <mgedmin> the number stays constant if I run gnome-settings-daemon -r when media keys _are_ working
[08:18] <darkxst> weird
[08:18] <mgedmin> conclusion: the bug is caused by gnome-settings-daemon getting blocked on something so it stops responding to key events
[08:18] <mgedmin> I'd like to run strace on it
[08:19] <darkxst> but it only affects media key plugin, so my guess would be a stuck grab (in mutter)
[08:20] <darkxst> well atleast I havent heard of, or seen other bugs that would indicate g-s-d is blocked
[08:23] <darkxst> although I wouldnt have though a stuck grab would only affect media keys, it should probably affect all keybindings?
[08:23] <darkxst> do things like <super>+L, <super>+M still work?
[08:24] <mgedmin> strace tells me 5 of them are in stuck in futex() and two are actually working (poll., read, recvmsg etc)
[08:24] <mgedmin> things that do not when the bug is active: lock screen, print screen, volume keys, brightness keys, ctrl-alt-del
[08:24] <darkxst> well of course, you can't have 2 g-s-d running under the same user
[08:24] <mgedmin> things that work when the bug is active: <super>+m, alt-tab, basically all window management keys
[08:25] <darkxst> mgedmin, just add as much info as you can, to the upstream bug
[08:26] <mgedmin> curious: I killed all my 'gnome-settings-daemon -r' respawns-but-the-last
[08:27] <mgedmin> then I killed the original /usr/lib/gnome-settings-daemon/gnome-settings-daemon
[08:27] <mgedmin> and after I did that, my gnome-terminal theme reverted to ubuntu purple
[08:27] <mgedmin> I still had one gnome-settings-daemon -r (the one with largest pid running)
[08:27] <darkxst> the keygrabber is a beast of a thing, due to limitations in X, I don't know enough about it though, to really understand what might be going on
[08:27] <mgedmin> and then another Alt-F2 r gnome-settings-daemon -r made the theme come back
[08:27] <darkxst> mgedmin, yes themes require a g-s-d running
[08:27] <mgedmin> so now I have only one gnome-settings-daemon
[08:28] <mgedmin> I'll try to strace it while I do a VT switch
[08:29] <darkxst> mgedmin, or ask on #gnome-hackers
[08:29] <darkxst> probably not many around now until monday though
[08:30] <mgedmin> I'd love to know if anyone can reproduce this not on ubuntu
[08:30] <darkxst> fire up a fedora image in a VM
[08:31] <darkxst> and no vbox doesnt count!
[08:31] <mgedmin> the strace is boring: the usual poll(), read(), recvmsg(), and then four write()s with the assertion failure, and then more recvmsg(), poll(), read() and the futex() that makes it freeze
[08:32] <darkxst> often the case
[08:41] <mgedmin> uh, what's the best way to get and unpack the source package from the staging ppa?
[08:42] <mgedmin> I know about echo deb-src ... >> sources.list + apt-get update + apt-get source, but wonder if there's something simpler, like pull-lp-source?
[08:42] <mgedmin> or a bzr branch that you use?
[08:46] <darkxst> mgedmin, I use chdist
[08:46] <darkxst> but if you just want one, dget <dsc file>, for which you can get the link from lp
[08:47] <darkxst> although if the ppa is installed and you apt-get source, you should get the right one
[08:47] <mgedmin> if I have the deb-src lines, but I don't think add-apt-repository adds those by default
[08:48] <mgedmin> my /etc/apt/sources.list.d/ is a mess after all those upgrades
[08:48] <darkxst> yes you need to manually enable them for ppa's
[08:48] <darkxst> mgedmin, chdist is very nice, especially when I am working with a few different ppa's
[08:49] <mgedmin> from the manual page I didn't realize it could help when dealing with ppas
[08:50] <darkxst> mgedmin, imagine a normal apt config in a chroot
[08:50]  * mgedmin -> lunch
[08:50] <darkxst> so each chdist you create has a sources.list and a sources.list.d dir
[08:51] <darkxst> you can even run installs in them, to check dependency issues
[08:51] <darkxst> (doesn't actually install anything)
[15:28] <zerschmetterling> hi all, how can I find the SMC credentials of a network share I have "permanently" configured as an item within Bookmarks in nautilus?
[15:29] <zerschmetterling> SMB credentials, sorry
[19:08] <bobthebuttblaste> is this where I go for support?
[19:08] <bobthebuttblaste> because I recently upgraded to 15.04 and then this happened: https://i.imgur.com/3RsCjje.png