[02:18] how do you get around the virtualbox black screen? [02:18] or corrupted screen? [02:19] Pwnna: check out the release announcement (it has instructions) and other things worthy of note: http://xubuntu.org/news/14-10-release/ [02:19] pleia2: thanks! [02:19] i missed it! [02:20] sure thing :) [02:20] it's been a real pain during virtualized testing this cycle, was a shame we couldn't get it fixed :( [02:22] i see fixed released [02:22] so if you apt-get upgrade it should be fine? [02:22] also => has anyone have trouble with the kernel that came out two days ago? I can't boot anymore with an encrypted partition [02:24] looks like the person who marked it fix released believes it was fixed in the daily yesterday, but I don't know who they are [02:25] (and their launchpad info is...sparse) [02:27] okay [02:27] another quick question. i noticed xubuntu-restricted extras [02:27] is that what i'm supposed to be installing instead of ubuntu-restricted-extras? [02:28] it's the same thing [02:28] i see slightly different packages installed, though [02:29] Source: ubuntu-restricted-extras [02:29] * pleia2 shrugs [02:36] is there like an equivilant of a commit log for xubuntu so i know what changed? [02:37] i manage a couple of boxes and it's sometimes a pain to upgrade versions as i have conflicting provisioning [02:38] it's only per package [02:38] no "all changes in all of xubuntu" massive changelog [02:39] changelogs for a package will live in /usr/share/doc/PACKAGENAME [02:40] I need to get some rest [02:40] have a good $time_of_day :) [02:40] night [04:03] Pwnna: heading to bed myself... but we have a pretty comprehensive changelog on https://wiki.ubuntu.com/UtopicUnicorn/ReleaseNotes/Xubuntu [04:07] you can view individual debian/ubuntu changelogs here http://packages.ubuntu.com/utopic/xfce4-power-manager (replace with the package name) [04:07] heading to bed for real now [05:38] pleia2: THe source package can be basically anything though, ubiquity-slideshow-ubuntu contains the Xubuntu one too. But yeah, don't think there's really much different between those two. [07:24] Found Ubuntu Vivid Vervet (development branch) (15.04) on /dev/sda8 [07:26] Not that early I'm not. :P [07:27] lol [07:27] not in it atm - installed it and got it in grub [07:28] every cycle I tell myself I'll sort out some other way of what to install in a clean one - and each cycle I resort to memory :) [09:15] bluesabre, tweeted your 14.10 article from @Xubuntu [09:16] morning knome [09:16] hey elfy [09:17] * elfy really wants to see 1 ppa that he can use for updates etc this cycle :) [09:18] 1 ppa... that might be too much to ask:P [09:18] but yeah, it should be mostly coordinated [09:19] I figure that at the least I should be updated to things *dev* are expecting to release *soon* [09:20] I guess that'd be the staging one [09:20] * knome drops the PPA descriptions to the processes page for completeness [09:21] bit hard to see the wood from the trees on the pad [09:21] ^ hope that'll help [09:23] knome: done or doing? [09:24] doing [09:24] awesome sauce [09:27] the wiki just went slow [09:27] it was bearable until now [09:30] 500 Internal Server Erorr [09:30] *Error [09:30] * knome sighs [09:32] ok, done [09:33] updating the wiki pages for vivid [09:37] done [09:53] knome: thanks - can see processes change [09:53] great [09:54] knome: though I'm still not sure which of those two people will send things I need to see to though :) [09:55] staging [09:55] extras is just "nice things to have" [09:55] cool - now we just need to make sure people use it lol [09:55] like "hey, there's this new cool piece of software, you might want to use this" [09:55] yep - understand now [09:56] ^ Mainly mine. :P [09:56] elfy, and kind of pre-staging [09:56] "let's see if we want to start the process of getting this included in the repos" [09:58] and where's that? [09:58] ^ that's the extras PPA [10:24] Generally not one you'd be interested in. :P [10:24] guessed :) [11:36] elfy: early in the cycle, things that land in debian sync their way over to xubuntu automatically. We can add more daily things to -staging if you'd like though [11:36] we can even add daily xubuntu-default-settings to staging [11:37] bluesabre: mostly it's about *our* things as far as I'm concerned [11:37] we don't test 99% of what we install - other than making sure it doesn't all go bang :) [11:38] all I'm interested in QA being interested in is the stuff we've got a modicum of control over [11:38] ok [11:38] so yea - things like xubuntu-* :) [11:38] alrighty, I'll set daily xubuntu- and shimmer- packages to the -staging ppa [11:39] that would be a good start :) [11:39] wait [11:39] i'm not sure if that's how we imagined the PPA [11:40] i think it's fine to do that [11:40] but if we do that, we should change the description of the PPA [11:40] well, nvm [11:40] i guess the current description is fine [11:41] just wasn't my mindset ;) [11:41] yeah, if it's xubuntu-/shimmer- we clearly plan on a nearby release [11:41] i was considering the daily aspect [11:41] but the description covers that [11:42] though i guess there's still that question [11:42] should -staging be a "high traffic" PPA [11:42] or should we separate the daily builds [11:42] probably not [11:43] frankly I don't care what we call it - what the description is - all I need is that we have a ppa that DOES include the things that *we* are updating and having them in one place so we can test things as they arrive [11:43] as long as it doesn't turn into a daily buildfest of everything we seed ;) [11:43] i'm just considering the practicalities [11:43] that'd probably be more of a daily breakfest [11:44] if using a staging PPA requires me to download 400 megs of updates, it's almost as bad as just downloading the new ISO :P [11:44] (daily, that is, it doesn't matter if that happens now and then) [11:44] if the ppa is pointed at dev then how many people will see it now - and for that matter between now and March? [11:44] yeah, that makes sense [11:44] if the ppa isn't pointed at dev - then we need one that is I guess [11:45] if someone wants to add a ppa we use to test dev stuff into a trusty install that's their issue to deal with [11:45] elfy, i'm not worrying about the end-users... to begin with, i'm worried about the team willing to do the updates daily [11:46] or bi-daily, or a few times in a week [11:46] it's a bit meh if it's a huge load every time [11:46] well ... [11:47] how many -team ran utopic ? how many are running it now? how many even knew what it looked like at the beginning of cycle? [11:47] a good portion of team run with the stable until pretty late in the cycle [11:47] well, [11:47] frankly I would wonder about anyone but me seeing what's going on with vampire for months [11:47] shouldn't the staging PPA be for several releases anyway? [11:47] if it is, people who run a non-development version can help as well [11:48] but they probably don't want to do it if it involves downloading hundreds of megs of updates every day [11:48] the systemd transition is planned for the first half of the cycle... I might avoid running as my fulltime install until that lands [11:48] then it's just pointless and I'll be back to adding ppas all over the place and having no idea what's going on - again [11:49] I think we've done a good job of consolidating the PPAs [11:49] elfy, i think you're getting me wrong [11:49] knome: possibly ;) [11:49] what i'm saying is that [11:49] if anybody does a new build we want, we copy it to one of our three official PPAs [11:49] since all of -team is not going to run the development version [11:49] it's better to allow them to test the new *packages* with their versions [11:50] which is why the staging PPA should have packages for other releases as well [11:50] BUT [11:50] i don't think it should turn into a daily buildfest that means we'll get hundreds of megs of updates daily [11:50] it's not going to do that currently [11:50] i'm not opposed to adding xubuntu-default-settings [11:50] right [11:50] but we should consider what's the scope of that PPA [11:51] eg. i don't necessarily want all xfce packages there [11:51] or "half of gnome" [11:51] because we're preparing a small bugfix for those packages [11:51] or sth [11:51] I need to head to work, but can you guys paste the result of this discussion over to http://pad.ubuntu.com/xubuntu-v-dev ? [11:51] I want a ppa that has up to date ANYTHING that we care about in it [11:51] I don't want last months menulibre - I want todays [11:51] elfy, would it be too bad if it was 2-3 PPA's? [11:51] what's the point in testing that ? [11:52] theoretically, that is [11:52] for things like that... I release menulibre, then upload it to debian, then it syncs to xubuntu in 24 hours [11:52] there should be a today ppa - with all that we care about [11:52] define "all that we care about" [11:52] everything that is seeded in xubuntu? [11:53] no - the things we've got control over [11:53] right, so i think that's what you'd call staging [11:53] I couldn't care less about something I've got because xubuntu is based on ubuntu [11:53] or what i'd call staging, that is [11:53] bbl [11:53] hf bluesabre [11:53] cya later bluesabre [11:54] elfy, just let's not make that a bloated PPA with too much stuff [11:54] knome: as I said I don't care what it's called - or what it's description is - as long as it has up to date things [11:54] so it's less of a thresold to actually start using it [11:55] knome: yea - I don't want a ppa with half an iso in it :) [11:55] and as bluesabre said, we probably want to land stuff to debian where appropriate [11:55] like menulibre [11:55] those packages are naturally not available for people not running the development version... but that's another question [11:55] can we please not get sidetracked on packages that land elsewhere [11:55] you know what I'm talking about [11:56] we're not sidetracking; you mentioned menulibre previously [11:56] as an example - choose another one [11:56] lol [11:56] mugshot then [11:56] it's pretty obvious what I'm looking for here [11:56] is that even in debian? [11:56] oh good lord [11:56] sure [11:57] to me, it's ok if some packages lag behind a few days if they're going through to debian and synced back [11:57] and the reason why i'm saying this is [11:58] that i don't think those packages necessarily need to be in -staging [11:58] which i'm sure you agree with [11:58] depends what package you're talking about [11:58] pretty much anything that will go to debian anyway [11:59] does xubuntu-default-settings go anywhere? [11:59] do any of the xubuntu-* go anywhere? [11:59] sure, they can go to the daily PPA [11:59] probably not xubuntu-docs [11:59] well, even that depends [12:00] probably not as daily builds :) [12:00] I;m not sure I've got the patience to do PPAs again :| [12:00] but we can certainly use -staging for staging big changes there [12:00] and before, when i said daily PPA, i meant the -staging PPA... [12:00] so just one PPA still [12:05] I just really am having a hard job understanding why it's not obvious that I'd want to have the latest theme/settings/versions to test [12:05] no-one else tests the whole shebang in team [12:06] if it's that hard to do or understand then I'll not bother and I'll just test what I get from the standard repos [12:14] we have daily builds for everything in the various project PPAs (menulibre-developers, parole-developers, shimmer-developers), we can also have then build to -staging. Or just the various themes and xubuntu things. At the same time, we don't want to rely exclusively on the PPAs because then we might not notice if some things are never actually uploaded to xubuntu. We'll have to do a careful balance [12:15] just food for though [12:15] t [12:15] out again, bbl [12:15] cya [12:16] let's see if I can break nvidia and vbox today [12:17] I guess I'm just still confused about the PPA situation - I thought that we were going to deal with it all [12:21] brb [12:25] oh wow, lotsa backlog [12:26] i'll catch up later today, out for lunch [12:26] bluesabre, agreed [12:26] off -> [12:30] well nvidia isn't broken :) [14:48] Unit193: ah, thanks :) [17:17] bluesabre: awesome post on 14.10! [17:53] hey sergio-br2 [17:54] hey ochosi :) [17:54] how're things? [17:54] evening ochosi [17:54] oh hey elfy :) [17:54] everything fine ochosi, and you? [17:54] quite good [17:54] had an important deadline today [17:55] so i'm exhausted/relaxed [17:55] can't really decide which one it is :) [17:55] awesome :) [17:56] lol [17:57] join the club ochosi [17:57] * ochosi signs the papers and joins slickymasterWork's club [17:57] welcome aborad [17:57] *aboard [17:57] or abroad - depends which country this club is in :p [17:58] sergio-br2: i saw there were quite a few new icons in elementary, but dan is a lazy bastard and only does a single size mostly... [17:58] hehe [17:58] heh [17:58] on top of it all I managed to screw my Verocius Velociraptor box [17:58] \o/ [17:58] sergio-br2: so yeah, if you feel like it again, join me in scaling icons ;) [17:58] well done slickymasterWork :) [17:58] i need to comeback to elementary-xfce [17:58] ok [17:58] bah [17:58] i think i have some icons here, that i didn't commit yet [17:59] slickymasterWork: wait, no animal coitus talk in this channel! [17:59] ah ah ah [17:59] that said, i hope he didn't scratch you [17:59] sergio-br2: oh, in that case please push them :) [17:59] the other way around [17:59] sergio-br2: i'd like to scale the new trash icons, those look nice. but lots of work... [18:00] work in this icon theme seems infinity :) [18:01] yeah [18:01] well we can always decide to stop [18:01] it won't really break much [18:01] but yeah, with gtk3 evolving and gnome needing new icons every release, i guess maintenance never ends [18:03] ERROR: Kernel configuration is invalid."; [18:03] include/generated/autoconf.h or include/config/auto.conf are missing."; [18:03] Run 'make oldconfig && make prepare' on kernel src to fix it."; [18:03] >_< [18:04] well I never need to do any of that .... [18:04] that's 3.18rc1 for you elfy ;) [18:04] :p [18:05] can't get more cutting edge than that :P [18:09] \o/ [18:09] fixed [18:09] back in business [18:11] running home [18:11] cy later guys -> [18:41] elfy: any news why the qt theming is broken all of the sudden? [18:41] I does not look like it's xubuntu's fault I'd guess [18:54] ok, all mirrors on the download page are now synced [18:59] brainwash: i think it's not broken, it just doesn't use the gtk+ look by default [19:04] ochosi: not anymore, maybe it can be fixed somehow for xubuntu [19:06] not anymore? [19:06] what i meant was: qt apps don't use the gtk look by default, but if you install qt4-qtconfig and set the style to gtk it works [19:06] so it's not broken in this sense, it just uses the wrong setting [19:08] it seems to work fine in 14.04, people just started to complain this recently [19:08] http://ubuntuforums.org/showthread.php?t=2249765 [19:09] bug 1382741 [19:09] bug 1382741 in xfce4-settings (Ubuntu) "Some apps are displaying a very old styled theme as oppose to greybird" [Undecided,Confirmed] https://launchpad.net/bugs/1382741 [19:10] yeah, i know [19:10] as i said... [19:10] i noticed it too, but only on monday, so it was too late for 14.10 [19:10] also, i noticed it and forgot about it again, cause i was a bit too busy [19:11] ah, ok [19:11] it's a candidate for the known issues list [19:11] yup, indeed [19:12] can the list be edited after release? [19:14] i guess so, never had to do that so far [19:15] knome: any experience with editing the known issues list after the release? [19:18] our bit of it? [19:18] ochosi: ^^ or the main that we just include [19:19] our bit [19:19] brainwash: I've never really had qt apps look ok without using qt config to set it to use gtk+ [19:19] ochosi: just edit it - it's our wiki [19:20] brainwash: it never worked fine in trusty - at least now with qt stuff I had [19:20] wait, but this one isn't editable: https://wiki.ubuntu.com/UtopicUnicorn/ReleaseNotes/Xubuntu [19:20] yes it is [19:20] oh right [19:21] at least it is here [19:21] i was just confused by "immutable page" [19:21] oh - you not logged in? [19:22] i wasnt for some reason [19:22] :) [19:22] added that line [19:22] brainwash: was there a bugreport for this already? [19:25] I've linked it [19:25] oh, whoopsie [19:25] * ochosi is tired [19:26] mmh, so it is a new bug after all? elfy? [19:26] what is? [19:26] anyway, gotta head out for dinner, will check in again later [19:26] this probably needs more investigation tomorrow [19:26] qt theming [19:26] cya later ochosi [19:26] yup, cyalater [19:26] bye [19:27] qt theming didn't work for me properly in utopic, trusty and saucy - but then I only use clementine [19:27] so no - it's not new - at least not to me [19:28] I noticed that more and more people talk about the broken theme in qt apps [19:28] and they all use 14.10 [19:28] perhaps people are just using more qt apps [19:29] like vlc? people are using this one for ages already [19:29] brainwash: I never really take a lot of notice of that type of issue - if we seeded it I might [19:30] adding a small hint for xubuntu users should do the job [19:30] yep - I never even thought about mentioning I always have to install qt config tool tbh :) [19:31] ok then :) [19:32] posted on forum thread [19:36] awesome, thanks [19:37] oh - that bug I posted in with the qt4 config thingy ... [19:44] also that's 2 issues I guess [20:23] knome: so did you mean the release notes? [20:24] no [20:24] yep - saw :) [20:24] :) [20:25] knome: the online stuff - our xubuntu-docs ? [20:26] because it's in there [20:27] right.. [20:27] maybe we should rethink the wording [20:27] that section immediately thinks that the user wants the latest regular release [20:27] yea was just looking - if nothing else we can talk about more recent releases :p [20:28] yep - I'd say two distinct sections - LTS and non I would have thought [20:28] yep [20:28] something like that [20:28] i'll file a bug [20:28] yep [20:29] I can look at writing it perhaps - but I'm not sure I've got whatever docs use [20:29] or if not I can pad it for whoever does fix it [20:31] bug 1385479 [20:31] bug 1385479 in xubuntu-docs (Ubuntu) "Review/-write section about upgrading" [Undecided,New] https://launchpad.net/bugs/1385479 [20:32] confirmed that [20:36] thanks, and added a comment [20:40] oh - lordy - that's in an xml file - not playing with that ;) [20:41] lol [20:41] well [20:41] docbook is relatively easy [20:41] as long as you just follow the example (which is carefully set in the docs), you are fine [20:41] so's wiring a jumbo jet ;) [20:41] heh [20:42] i don't mind if you write it in plaintext in a pad, i can easily convert that to docbook [20:42] knome: if there's no rush I'll look at it - if not I'll plaintext it in a pad [20:43] of course there is no rush [20:43] the next release is in 6 months [20:43] ^ famous last words before filing freeze exception paperwork [20:44] ok - well I'll work on it - probably do a plaintext version first then not have to 'learn' at the same time :) [20:44] yep :) [20:44] fwiw, you might want to assign that bug to yourself once you start working on it [20:45] just did it [20:45] otherwise you might be doing duplicate work with jjfrv8, who's been picking these bugs up like a master [20:45] yep [20:47] and also, if you want to try poking docbook, feel free to mark me as the reviewer for a merge proposal and i'll go through it [20:48] altogether just trying to build the docs is a good sanity check because it'll tell if you the syntax is all wonky [20:50] docbook means nothing to me - I assume it's not editing xml files directly [20:50] docbook is a form of xml [20:51] xml is a very broad term for documents that have different tags and attributes and content for them [20:51] docbook specifies its own set of valid tags [20:51] ok - so how do you poke docbook? or do you mean edit that file I've pulled? [20:52] that's one way to do it [20:52] and there are also editors that can do it [20:52] but i don't believe in such things myself :P [20:52] heh [20:52] I guess if you do it manually - you'll learn more [20:54] anyway - plaintext first :p [20:56] yep [21:50] elfy, if you want I can share that burden with you [21:51] I'd like to carry it for a while :) [21:52] ok docbook wise, if you need help, just ping [21:52] we can come up with something else for slickymaster :P [21:52] :) [21:52] at your service [21:53] ha ha knome [22:48] https://packages.qa.debian.org/x/xfce4-session/news/20141024T124946Z.html most interesting of the recent uploads. [22:50] hm [22:52] Yes, the last bit about the postinst being the most interesting. [23:05] ahoj crew [23:11] good idea with the docs [23:11] the extended upgrading info makes sense [23:11] yes [23:14] knome: just as a "note to self", should we carry the greybird-a11y version forward to 15.04? [23:14] yep [23:14] i'd really like to see it, i just don't see time to do it right now [23:14] yep [23:14] especially as gtk3.14 will be a rather biggish change [23:14] mhm [23:14] satya said he wants to completely redo the theme in SASS [23:15] hrr [23:15] might be more sustainable, but initially lotsa work... [23:15] didn't the decide those markups aren't supported anyway in later gtk versions? [23:15] or do i just remember wrong [23:15] redoing in sass... [23:15] not too much work [23:15] what markups? [23:15] well SASS and stuff [23:16] wait, the adwaita theme (==gtk default now) is in SASS atm [23:16] right [23:16] they just ported things over from css, it'd be totally weird if they at the same time planned to deprecate it (but who knows) [23:16] then i'm maybe misremembering [23:16] any idea where you picked that up? [23:16] no [23:16] i'll tell you if i bump into it again [23:16] anyway [23:17] doesn't that mean an addiotional dependency? [23:17] because obviously it needs to be preprocessed [23:17] also a potential performance question? [23:17] not sure [23:18] or is it just preprocessed on build/installation time? [23:18] i guess gtk3 processes it [23:18] not sure tbh, i haven't looked into it *at all* [23:18] frankly, i'm not too into it [23:19] https://git.gnome.org/browse/gnome-themes-standard/diff/themes/Adwaita/gtk-3.0/parse-sass.sh?id=349d83bfc2ce52faab7de0b73835151cc65c8100 [23:19] i would have been very surprised if gtk parsed sass. [23:20] yeah [23:20] i guess that the idea is to keep to code more maintainable by remaining "in touch" with adwaita [23:20] right [23:20] so my quick thoughts: [23:20] parsing is meh. [23:20] if we do it build-time, real-time/quick changes are gone [23:21] if we don't, it's a performance issue [23:21] sure, it can make the theme a bit smaller [23:22] migrating to SASS just to keep "in touch" with adwaita is a bit silly thought too [23:22] we can always write a parser that translates SASS from adwaita to css though, right? [23:22] any SASS code is rather easily convertable to CSS anyway, so if we decide to pick an update, we can get it even if adwaita was in SASS [23:22] then keep in sync with that [23:22] of course there is already a SASS->CSS parser [23:23] SASS wouldn't exist without one, because nothing directly supports it (afaik) [23:23] the most practical issue is that it's sorta up to satya, because he mostly maintained our gtk3 variants [23:23] so in a way SASS *is* the preprocessor that processes the SASS definitions to CSS [23:25] to be honest, i don't think it's such a huge issue we/he is making it [23:26] well if he's *making* it, it's up to him to decide [23:27] heh [23:27] let me give you an exampel [23:27] example too [23:27] sure === CajunTechie is now known as cajuntechie-afk [23:29] sass --update -r custom_functions.rb . <- so this adds a build dep on sass and ruby? [23:29] http://paste.ubuntu.com/8662945/ [23:30] ali1234, probably don't need the ruby build dep if we don't use the funky custom functions [23:30] hmm, i'm lacking one } [23:30] but whatever [23:30] ochosi, ^ you get the idea [23:31] sure, i get it [23:31] but i also get why people would think that one is more readable and in this sense more maintainable than the other [23:31] but while that looks useful [23:31] it's not too useful in all situations [23:31] and since gtk3 breaks theming every release cycle... [23:31] that's one of the best examples [23:32] right, what are you aiming at exactly? :) [23:32] well just showing the difference [23:32] (sorry, i was already tired in the afternoon) [23:32] and kind of telling it's easy to convert to SASS and back to CSS [23:33] it isn't a huge load of work [23:33] i'd say an hour or so [23:33] per theme [23:33] you missed out that sass/less support constants [23:33] well, maybe a bit more.. [23:33] ali1234, that's supported in GTK already [23:33] border-color: shade(@theme_selected_bg_color, 0.8); [23:33] we have rows like that [23:34] so we're not gaining much in that respect [23:34] reading the changelog, it seems like adwaitas funky ruby scripts had something to do with mixing colors [23:34] but didn't look too closely into that [23:36] https://git.gnome.org/browse/gnome-themes-standard/diff/themes/Adwaita/gtk-3.0/custom_functions.rb?id=349d83bfc2ce52faab7de0b73835151cc65c8100 [23:36] provide custom sass functions for gtk equivalents [23:36] - generally sass has equivalents of gtk functions for mixing color in the case of the spinner though, the currentColor only lives in the context of gtk runtime. gtkalpha() is a way to provide alpha() in gtk context rather than SASS alpha() [23:36] ^ that [23:37] and yeah, sass seems to require ruby anyeay. [23:37] *anyway too [23:38] is it not written entirely in ruby? [23:38] i have no idea. [23:38] https://git.gnome.org/browse/gnome-themes-standard/diff/themes/Adwaita/gtk-3.0/gtk-dark.css?id=c10689c7b2dc1352e7b329f58c9f653e5682dca5 [23:38] ^ ochosi: i want to cherry pick that commit to that file [23:38] it is [23:39] whaaaaat is that? [23:39] a fail [23:40] heh [23:40] overwrote the input with the output? [23:40] just proves what can happen if SASS definitions fail [23:40] which failed, and then commited it? [23:40] well, committing bs can always happen though [23:40] ali1234, i have no clue how that happened, but it's a fail [23:41] ochosi, of course [23:41] it just seems to bring one layer of more complexity [23:41] which is odd, as it's supposed to reduce complexity [23:41] even if it took away one layer of complexity away elsewhere [23:41] oh i see what happened [23:41] well of course there's one more layer of work to do because the SASS will need to be processed to CSS [23:42] they've tried to put all @imports inline with a script [23:42] but that one has failed [23:43] maybe i should go to sleep, i start seeing images in the irssi window [23:44] heh, sounds like it [23:44] oki, i'm off [23:44] ttyl [23:47] night knome