=== pgraner is now known as pgraner-dr [12:56] hi [12:57] I need to report a bug which is in the Ubuntu kernel and affects the behavior of the zram-config script. I hope this one will be a lucky #bug: [12:57] https://bugs.launchpad.net/ubuntu/+source/zram-config/+bug/1449678/comments/13 [12:57] Launchpad bug 1449678 in zram-config (Ubuntu Vivid) "(Vivid) zram-config 0.3 Job for zram-config.service failed" [High,Fix committed] [12:57] I'll be around [12:58] any one having the right method to advice me about reporting the issue linked to kernel is welcome to tell me how [13:07] melodie, if there is a kernel component, then the bug should be "Also affects Distribution/package" linux [13:07] apw let me see... [13:08] apw and think : this does not affect the behavior or usability of the kernel. It's the way the compiling options have been treated which generates the bug [13:09] melodie, i am not sure what the bug even is really from the report [13:09] zram_lz4_compress=y and config_zram=m [13:09] the original bug: [13:09] the zram-config script (vivid hence with systemd) was not working right [13:10] after a debug I did, Didier Roche was able to correct it, but I still had only one zram block created and having 100 as priority, instead of 2 block devices (I have a dual-core) and 5 priority. [13:11] it appeared when seeking for the source of the issue that I could not even unload it: it was used by config_zram_lz4. [13:11] why does the number of cpu's you have have any relevance to the number created ? [13:11] apw it has [13:11] why ? [13:11] they are ram compressed disks, how does that relate to how many cpus i have [13:11] believe me or check with the compcache original project and the zram-config script [13:11] this is how it is supposed to work [13:11] /* Module params (documentation at end) */ [13:11] static unsigned int num_devices = 1; [13:12] well the source code defines it to be 1, always [13:12] unless it is overridden, so they don't take number of cpus into account [13:12] not indeed do i understand why the defaults would [13:12] it used to [13:12] not sure it still does though [13:12] anyway the scripts I use have always stated one block device per cpu and the present script has not changed that part [13:13] and comparing todays zram with the ancient compcache wont give you much valid info i fear [13:13] and this is how I suspected that the zram module was loaded at boot instead of letting the zram-config script do it's job [13:13] ogra_ hi [13:13] well, but probably the code in-kernel changd [13:13] *changed [13:13] ogra_ I have followed your advice and went to Didier Roche directly. [13:13] :) [13:13] ogra_, well the default in P was 1, and the default in vivid is ... 1 [13:14] so its not changed as far as i can see [13:14] now his script works for me, but only as long as I blacklist zram in the blacklist.conf file [13:14] "his" ? [13:14] apw, hmm, in precise it definitely created one per core [13:14] so you devs do what you want with the information : if you want to get all Lubuntu users come and yell later, it's up to you [13:15] apw yes, Didier Roche version which switches the former script to systemd method [13:15] ogra_, its not clear how it could do that, from the code in precise [13:15] ogra_ apw I summarized here: https://bugs.launchpad.net/ubuntu/+source/zram-config/+bug/1449678/comments/13 [13:15] Launchpad bug 1449678 in zram-config (Ubuntu Vivid) "(Vivid) zram-config 0.3 Job for zram-config.service failed" [High,Fix committed] [13:15] this is what I see and this is what you get :D [13:18] I don't have your skills at reading the source code from the zram module, I just do my best as a tester. :) [13:18] and I have been using compcache/zram since 2006. :) [13:18] yep, and i am simpy trying to understand what is going on [13:19] as clearly the code does not do what is claimed, so as you clearly see the behaviour something else must be doing it [13:19] does not internally do what is claimed [13:20] apw simple: if zram is not blacklisted, the zram-config script, which allows loading it with some well thought options, and allows choosing wether or not use zram does not work; [13:20] so the actual setup of the kernel configuration file makes the existence of the zram-config pointless. [13:21] and does not leave the choice to the administrator : with or without? with or without custom choices? no choice ! [13:21] just take it or blacklist it. [13:22] melodie, yes sounds broken, so ... why did it work before, or more specifially [13:22] apw I can try to help you with that if you are one of the persons taking care of it? [13:22] i assume the scripts assume the module is not loaded, and for "reasons" it is loaded [13:22] what the heck is loading it [13:22] it doesn't sound like it should be really unless you need it [13:23] I try to extract an information lost in my messages, wait a sec please [13:24] apw compare the result on the cat /proc/swaps in #13 with what I got when zram was default loaded: [13:24] $ cat /proc/swaps [13:24] Filename Type Size Used Priority [13:24] /dev/zram0 partition 947216 0 5 [13:24] $ [13:24] ok cirtianly the scripting just makes the assumption it is not attached [13:24] and I now try to find another key information I posted [13:27] ok, got it: [13:27] when zram was default loaded (not with the script): [13:27] $ lsmod | grep zram [13:27] zram 24576 1 [13:27] lz4_compress 16384 1 zram [13:27] $ [13:27] this is in the mail I sent to Didier Roche 2 weeks ago [13:27] now with the script working while zram is blacklisted: [13:28] # lsmod | grep zram [13:28] zram 24576 2 [13:28] lz4_compress 16384 1 zram [13:28] # [13:29] when I saw that first, my thought was that lz4_compress was calling it while the boot occurred. I may be wrong, I have very little experience of fiddling with the kernel (compiled twice only and that was long ago, just to say... ) [13:29] could be [13:29] what change occurred which is very important and I didn't even see it coming until I realized last month: [13:29] very important [13:30] zram is no longer in the staging directory! that is new for me ! [13:30] melodie, which kernel is this, which version [13:30] 3.19.0-22-generic #22-Ubuntu SMP Tue Jun 16 17:15:15 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux [13:31] apw, http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/precise/zram-config/precise/view/head:/debian/zram-config.upstart [13:31] and the former ones from the same series had the same problem with zram [13:31] it was the upstart script that did bump the number of devices === zyga_ is now known as zyga [13:32] via modprobe options [13:32] ok ogra_ and apw I hope my findings will help improve it. if you need me for some tests, please just ping me on the bug report? [13:32] hopefully we can continue using the script to keep control on it. [13:34] no, we cant, since the init system it was written for does not exist anymore [13:34] someone needs to port it to systemd ... (which i thought didrocks had done) [13:35] ogra_ sorry? why would Didier Roche adapt it for systemd? [13:35] didrocks has adapted it for systemd: this is my point [13:35] no idea, but he did that [13:35] and as the #13 of my bug report shows : once ZRAM blacklisted in blacklist.conf his scripts works perfect! [13:36] now I can "systemctl start/restart/stop" it [13:36] it works! [13:36] did anyone bother to check if systemd has some internal own handling of zram ? [13:36] (i.e. something that kicks in if the module is not blacklisted) [13:37] ogra_ I have been using in in Archlinux during the last years with systemd, and I have never heard about such a "internal" feature : it would not have been added anyway as long as zram was in the staging directory, which is a situation which lasted during several years. [13:37] perhaps it needs to be managed completely different in systemd world ... and "just porting" the old way doesnt work at all [13:37] ogra_ oh that [13:38] can someone ask to a redhad dev? [13:39] melodie, http://lists.freedesktop.org/archives/systemd-devel/2012-November/007437.html something to read for you :)) [13:40] ogra_, the module doesn't have any aliases, so it would have to be deliberatly mounted [13:41] apw, sure ... but it seems there are multiple userspace ways ... there is systemd-swap ... then there seems to be a udev rule for zram ... [13:42] i suspect there is some integrated way in systemd that needs to be used for it ... and adding a systemd unit with our old upstart script might be the completely wrong approach [13:43] ogra_, right but as zram is a virtual thing, someone needs to ask for it, for udev to even see it [13:43] ogra_ I'll try to read [13:45] ogra_ well at least he has the same references as I do [13:45] compache project and mystillef script [13:45] systemd-swap might be to blame for sure [13:45] apw, hmm, perhaps fstab ? [13:45] i don't think fstab can instantiate zram as it is not a filesystem [13:46] systemd parses fstab ... [13:46] and mount generally only triggers probes for filesystems [13:46] i could imagine it tries to ask for the module when finding a zram device [13:46] it looks like a very clean solution [13:47] I'm talking about ogra_ 's link [13:47] ogra_, could be, which would be a mess maker [13:47] i just think simply forward-porting the upstart way was wrong [13:47] i can say on a vivid/wily system i do not see zram loaded at all by default [13:47] ... and that there is some existing systemd way already [13:48] why would you see it loaded at all ? [13:48] ideally for user experience, ultimately, we wout like to get a gui with options that write in a zram.conf file, saying how many block devices we want, how large, or what %age of the ram we want them to be, along with advice for the best / recommanded practice. [13:48] ogra_, well if i did then it would be something else [13:48] in upstart it wasnt loaded either until you explicitly asked for it by installing zram-config [13:48] Just a wish... ^^ [13:49] ogra_, there was a contention it was the lx4 bits which triggered it, which it is not [13:49] else i would have it [13:49] ah [13:49] apw you mean lz4? [13:49] yep that [13:49] as in lzma ... [13:50] so this must be an interaction with osmething else ... and you are likely right it is systemd [13:50] which likley means the way this is integrated isn't going to work so well [13:51] with systemd, i wonder if we could get it to write a modprobe.conf with the appropraite options for zram [13:51] apw, http://lists.freedesktop.org/archives/systemd-devel/2012-November/007444.html [13:51] ..."we can just add to the fstab lines, which sets up everything as needed"... [13:52] lennart ... [13:52] then again, if you are using zram-config why would you have /etc/fstab bits listing it [13:53] so seems my assumption was right ... systemd-swap sets it up ... and you have to define each and every device in fstab ... so if you want more than one it wont be dynamic at all [13:54] if you are using zram-config you are using the old upstart script wrapped by a systemd unity [13:54] *unit [13:54] ogra_ I am not sure about that: [13:54] no need for fstab in this case [13:55] the mystillef method existed before Ubuntu makes use of zram [13:55] if you want to use the "new" systemd way you likely have to put a line for each zram device into fstab [13:55] and his script was used with the systemV init way [13:55] for instance, the former zram config script using systemV was adapted directly to systemd [13:56] no upstart method there [13:56] melodie, could you try uninstalling zram-config and then create fstab lines like in http://lists.freedesktop.org/archives/systemd-devel/2012-November/007444.html ? [13:56] if my theory is right you would then get zram devices as defined in there [13:56] ogra_ in a virtual machine, yes. Not right away though but within a few days possibly. [13:56] I could also ask the geeks of my tribe to test it [13:57] I mean : the most advanced users of the small linuxvillage.org community. :) [13:57] heh [13:58] I thought fstab was less used these days? [13:59] tell that to systemd :P [14:00] ogra_ my fstab is quite lite, one line per partition [14:00] and one line for proc [14:00] not sure it's even still needed: is it? [14:00] * ogra_ has systems completely without fstab [14:00] I mean the line for proc [14:00] ogra_ o_o how do you do that? [14:00] but i doubt that works in the age of systemd [14:01] mountall ships a default one [14:01] oh you don't have systemd. [14:01] ok [14:01] i do [14:01] but not on all machines [14:01] I meant in the one where you don't have a fstab (I sound obvious?) [14:02] I keep your two links and will summarize this interesting zram matter on the linuxvillage forum asap [14:02] right, there the default one just kicks in ... but not even that would be needed [14:02] sorry I have to leave the discussion now, I'm in the middle of another task [14:02] our initrd mounts / based on the kernel commandline ... [14:03] i'll bbl [14:03] so no need for an entry for / ... (unless you want explicit fsck) [14:03] /proc and /sys get mounted by the initrd too ... no need to have an entry for them ... [14:04] and /dev nowadays gets populated by devtmpfs [14:16] i am still somewhat confused why you would get zram loaded if you don't have fstab entries [14:16] even if systemd thinks it knows better, and i am sure it does [14:20] apw http://citrotux.org/Downloads/plot.svg [14:20] don't know if that can help [14:29] melodie, well it cirtainly happens pretty damn early in systemds startup, much before udev even starts if i read this right [14:29] melodie, and can you pastebin the fstab on that for me [14:39] melodie, do i recon put a link to that plot in the bug, as it is pretty indicative that somehow systemd is involved, though i cannot find zram in it by default [14:41] melodie, that there is a unit called .swap, implies we have actual configuration for the swap on zram somewhere [14:41] melodie, perhaps in /etc/systemd/system/*.swap [14:42] melodie, perhaps in /etc/systemd/system/*.swap* [14:44] I'll do that later, now I need to run out (dentist appointment) === henrix_ is now known as henrix === pgraner-dr is now known as pgraner === pgraner is now known as pgraner-dr [19:39] bjf, is there an invite for the kernel team meeting ? or a schedule for when the next one is ? [19:40] manjo, you mean the irc meeting? [19:40] bjf, yes [19:41] manjo, it's every Tue @ 1700 utc ... correct, jsalisbury ? [19:41] manjo, it generally runs for no longer than 5 minutes so you need to be there on time [19:41] manjo, do you have something you want to discuss? === swordsmanz is now known as hugbot === hugbot is now known as YEEEHAAWWWW [19:43] bjf, yeah related to ARM64 + UEFI + ACPI === YEEEHAAWWWW is now known as swordsmanz [19:44] manjo, any reason to not just bring it up here tomorrow a.m. when cking is around? no need to wait for the meeting. [19:44] bjf, plus get a general direction on where we are headed with ARM 8.1 support and smmuv3 support for 15.10 [19:44] sure I can do that [19:44] manjo, i think that's a better plan [19:44] bjf, I think that is a better idea [19:45] bjf, just curious .. thought cking was helping out with git support with launchpad ... or it could be the other colin [19:45] manjo, other colin [19:45] ok [19:49] bjf, I also need to know how often do you guys rebase leg onto ubuntu dev trees stable & unstable [19:50] bjf, so I will come with a list of agenda items tomorrow am [19:50] bjf, manjo correct. 1700 UTC [20:10] apw: I'm super confused by melodie's zram issues, and by everyone blaming systemd, since zram-config and systemd are working great here... [20:10] melodie: ^ [20:16] infinity ? [20:16] we can check that now if you want to? [20:18] infinity when you want : we can check which Ubuntu edition and version you have, and the results when you check status, start restart then stop and start ? [20:18] melodie: Not sure what there is to check. I'm using zram-config and systemd, and I get 4 swaps, as I should. ie: it's working correctly. [20:19] versions and editions? [20:19] melodie: zram-config 0.5 (which is effectively the same as the one in vivid-proposed) on wily, kernel 3.19.0-22 [20:20] Oh. No. kernel 4.0.0-3 right now, but I could reboot into 3.19.0-22 again to prove the point. [20:20] I have a kernel x86_64 3.19.0-22-generic systemd 219-7ubuntu6 [20:20] how can you get that one kernel? [20:20] I'd like to give it a try too [20:20] It's in the kernel team's PPA. [20:20] aha [20:21] ok, I won't do that right now [20:21] But I can't see this being a kernel bug. [20:21] I have two other tests to do first [20:21] The part where the SRU works for Didier on vivid, and 0.5 works for me on wily, though, leads me to believe there's something weird in your test setup, not ours. [20:21] what are your block devices priorities? 5 or 100 ? [20:22] Or maybe something weird in your flavour. Is this pure Ubuntu, or Lubuntu, or...? [20:22] root@nosferatu:~# cat /proc/swaps [20:22] Filename Type Size Used Priority [20:22] /dev/sda7 partition 4070396 0 -1 [20:22] /dev/zram0 partition 2557524 0 5 [20:22] /dev/zram1 partition 2557524 0 5 [20:22] /dev/zram2 partition 2557524 0 5 [20:22] /dev/zram3 partition 2557524 0 5 [20:22] (5) [20:22] yes, it looks perfect [20:22] this is pure ubuntu core with openbox as main component [20:23] core : I mean base system [20:23] melodie: No mention of zram at all in /usr/lib or /etc ? [20:23] Or /lib [20:23] such as what? [20:23] do I need to invoke find there? [20:23] Literally the string "zram". rgrep for it. We can figure out why things mention it if it's mentioned. :P [20:24] wait wait: right now it's working right since I have blacklisted the zram module, so this test would not be helping [20:24] melodie: The grep will still be enlightening. [20:24] I have to undo the zram blacklisting, then remove zram-config [20:24] ok, if you say so [20:25] rgrep zram /etc/ /usr/lib/ /lib/ [20:25] can chain them? [20:25] Yeahp. [20:25] It'll grind a lot and take a while. :P [20:26] yes, I started it as root to avoid the "forbidden" list [20:26] This is what I get: http://paste.ubuntu.com/11795400/ [20:26] I'll pastebin once finished [20:26] ie: no mention of it, except for the upstart/systemd jobs. [20:26] ah wait [20:26] I have to restart it with LANG=C [20:27] Doesn't really matter, I can divine what "Das binary containen der stringen" means. :P [20:27] (Or whatever) [20:27] :) [20:28] this one was done before I had the idea of blacklisting zram, http://citrotux.org/Downloads/plot.svg [20:28] does it "talk" to you? [20:29] humm it seems this one you don't have? "lib/udev/rules.d/60-persistent-storage.rules:KERNEL=="fd*|mtd*|nbd*|gnbd*|btibm*|dm-*|md*|zram*|mmcblk[0-9]*rpmb", GOTO="persistent_storage_end" [20:29] " [20:30] full output: [20:30] http://pastebin.fr/40331 [20:32] I wouldn't expect that to cause an issue, but I suppose anything's possible. Maybe I should test this in a vivid VM. [20:32] also you say you have zram-config 0.5 proposed in Vivid, but I have zram-config: [20:32] Installé : 0.3.1 [20:32] which is what I get as proposed in Vivid [20:32] No, no. I have 0.5 in wily, but it's basically identical to 0.3.1 in vivid-proposed. [20:32] what differs from 0.5 and where have you seen it proposed in Vivid? [20:32] oh ok [20:32] ie: the same fixes, just a different version number. [20:32] ok [20:33] * infinity grabs a vivid ISO... [20:39] infinity do you want my last test version? [20:39] very small [20:39] melodie: I'd rather see if I can reproduce it in a stock install first, but then, sure, yours might be useful. [20:39] http://linuxvillage.org/en/2015/05/bento-openbox-vivid-rc1-and-rc2/ [20:39] well here [20:40] just my home version is one I upgraded from the Bento 12.04 done previously to the 14.04 then from there to the 15.04. I was happy to see that it didn't break at any moment. [20:40] direct upgrades can be tricky sometimes [20:41] I want sushi-rc2? [20:41] http://downloads.linuxvillage.org/sushi-vivid-rc2-with-openresolv-x86_64.iso ? [21:10] melodie: Oh, hrm. Can you give me a pastebin of "update-initramfs -u -v" on the affected system? [21:11] yes infinity you want sushi, it is a Vivid with almost no appas [21:12] apps [21:12] rc1 or rc2 as you want, they are the same except for the resolver [21:12] melodie: Yeah, I installed a fresh sushi and can't reproduce your issue, but I have a hunch, hence the above request. [21:12] still don't mind that I have zram blacklisted and zram-config working fine? [21:13] Noe. [21:13] Nope* [21:14] infinity http://pastebin.fr/40332 [21:15] Ah-ha. [21:15] melodie: rgrep COMPCACHE /etc/ [21:16] in the way [21:19] melodie: My bet is that /etc/initramfs-tools/initramfs.conf:COMPCACHE_SIZE= is set to something other than an empty string. [21:19] melodie: If you set that to "" and re-run update-initramfs -u, everything would be happy. [21:19] And I should probably cripple initramfs-tools to ignore COMPCACHE_SIZE is zram-config is installed (and eventually tear that code out entirely...) [21:19] s/is/if/ [21:24] infinity let me check the output now, I was working on a SVG in the meantime, having a course with a buddy on another chan [21:24] # rgrep COMPCACHE /etc/ [21:24] /etc/initramfs-tools/initramfs.conf:# COMPCACHE_SIZE: [ "x K" | "x M" | "x G" | "x %" ] [21:24] /etc/initramfs-tools/initramfs.conf:COMPCACHE_SIZE="25%" [21:25] melodie: That would be the issue. The default for that is "" (ie: empty). [21:25] this is my fault then [21:25] let me fix it here [21:25] melodie: And if it's set, initramfs-tools will set up a zram swap before you ever get to init. [21:25] and I'll retry all of this tomorrow [21:25] o_o [21:26] melodie: So, yeah, change that to "", and then run "update-initramfs -u", and it should be happy even with your blacklist removed. [21:26] what I would like at the end, would be a nice /etc/default/zram.conf that is tweakable [21:26] do you think that could be possible? [21:26] melodie: A config file is a possibility, yeah. With it defaulting to what it does now (50% RAM, a swap per CPU thread). [21:28] a swap per cpu thread is what I am used to, the 50% ram does not match the observations done for use in desktops by nitin gupta, the creator of the compcache project, and I always used 25% as per his advice (which was working well enough for my greedy habbits) [21:29] what I also know since I had lots of discussions around the zram topic with other users, they like to do experiments and try 20/33 % or even fixed values [21:29] according to what their hardware are [21:29] melodie: Sure. We can definitely extend it to allow a config file, though that's not something I'd SRU back to older releases, we'd only see it in 15.10 and beyond. [21:30] this is fine with me [21:30] as long as it's a work in progress as we say :D [21:31] and after the 15.10 I'll come back and eventually as for a GUI (started with admin priviledge) [21:31] or better: [21:31] a tool as they have in Fedora and co! [21:31] let me see if I still have this pic somewhere [21:32] Given our usual urge for GUI simplicity, this isn't the sort of thing we'd usually want exposed in a settings UI. [21:33] Normal users should have zero need to tweak this sort of thing, IMO. [21:34] yes! [21:34] http://phillw.net/isos/bento-ubuntu-remix/misc/Downloads/Screenshots/Jobs/ [21:35] infinity Ubuntu is more used by advanced users than normal users now and I have installed Ubuntu (several flavors) to end users machines and I can tell you : when they don't know what a menu does they just don't touch it [21:36] so what we need this for, is for average and advanced users who are tired of having to remember every command line because the init systems have changed in time [21:37] melodie: None of that is about configuring things (ie: tweaking config files), that's just a tool to enable/disable/start/stop services. ie: it's a GUI systemctl. [21:37] and having to check the internet and wiki and docs is a bit time greedy too, and time is a good that is very precious nowadays [21:37] infinity yes, I am a bit mixing the topics, sorry :D [21:37] And I agree that shipping that would probably be a good idea. [21:37] but this is really what I meant in fact [21:38] the ability to start and stop services, including zram-config of course, would be good. [21:38] and "jobs" is still in the repos: I forgot to write a bug report! [21:38] to have it removed because it's been years since it's not working [21:39] last time I checked, Archlinux version of the tool was not working anymore either, and was not in the official repos, but the Fedoran version of the tool that I tried and used was really wonderful. [21:39] very detailed, very easy to use [21:40] if it can be adapted for all deb distros that would be wonderful. [21:40] melodie: I've updated LP: #1449678 with our findings above, BTW. [21:40] Launchpad bug 1449678 in zram-config (Ubuntu Vivid) "(Vivid) zram-config 0.3 Job for zram-config.service failed" [High,Fix committed] https://launchpad.net/bugs/1449678 [21:41] melodie: If you can reset that config variable, remove your blacklist, regen your initramfs, and verify that bug, it would be lovely. [21:41] (I can verify it here, but I'd prefer you do...) [21:42] infinity thanks for the update! [21:42] I'll be notified and will confirm accordingly. [21:42] next time I will have rebooted [21:42] (just not now) [21:42] * infinity nods. [21:43] :) [21:43] you had a very fine hunch. what is your skill exactly? what do you do in Ubuntu? [21:43] melodie: Everything. [21:45] o_o [21:45] would you have some time for some mentorship once a while? [21:46] melodie: I'd love to say yes, but the more honest answer is probably no. I tend to work a little too much as it is. But I'm always around to answer the occasional question, as long as you don't get offended if I sometimes don't reply or don't have time. :P [21:47] ok [21:47] on what other chans are you also? Here is for kernel and my questions might not be kernel related. [21:47] mostly about XDG_* variables, and later about packaging config files for ppa [21:49] melodie: Most generic development stuff belongs on #ubuntu-devel, unless it's newbie questions, which should usually be on #ubuntu-motu. [21:49] what is a newbie? XD [21:50] I consider myself still a newbie as I'm still climbing the learning curve, started 11 years ago :D [21:51] well never mind... one way or other I'll find how to do things the right way. Up to now, Bento Openbox is a proof of concept [21:51] it works [21:51] melodie: Well, "newbie" questions don't necessarily come from new users/developers. But if the question could be phrased as "help, I have no idea what I'm doing here" rather than "I know how this works, but it seems broken", then it belongs on -motu. The latter belongs on -devel. [21:51] technically it needs lots of improvements [21:51] nothing in between? [21:51] melodie: You have an installer bug on sushi, BTW. Doesn't remove all the installer deps before reboot. [21:51] melodie: But I'm sure you'll sort that one out. :) [21:52] infinity I know about it, it comes from the tool I use to remix [21:53] I didn't think of a way to use the filesystem manifest remove (or desktop, don't remember which one) and not sure the program allows tweaking it. [21:53] it's an issue but not the only one, I need to adress more than one issue. [21:54] not issues that the end user can detect, for him all works nicely. [21:57] infinity I have an idea of a test I could do [21:57] a fast one [21:57] a diff -aur on the one file I have and the one that exists in the lubuntu live iso [21:57] and tweak the file I use.. [22:00] thanks for saying! [23:48] good night