[08:03] <alan_g> RAOF: Did I answer your "Needs Info"? https://code.launchpad.net/~alan-griffiths/mir/placement-notification/+merge/305599
[08:06] <duflu> alan_g: Just a bit past his EOD
[08:06] <alan_g> Oh well...
[08:08] <alan_g> duflu: you picked up the crash releasing egl resources. You have an idea what's broken?
[08:08] <duflu> alan_g: Only started on it 15 seconds ago. Will comment soon if at all
[08:09] <duflu> Feels familiar but not sure why
[08:09]  * alan_g wants it NOW!! ;)
[08:09] <RAOF> Oh, I didn't respond to that.
[08:24] <duflu> Launchpad times out and becomes unusable
[08:24] <duflu> Must be morning in Europe
[08:25] <duflu> alan_g: I can't update bugs right now as LP times out. But it's just another Mesa 12.0.2 regression. 12.0.1 works
[08:26] <alan_g> duflu: I suspected as much, thanks
[08:26] <duflu> No problem. I still had the old debs handy from the other regression
[08:27] <duflu> alan_g: If LP works for you please just duplicate to https://bugs.launchpad.net/ubuntu/+source/mesa/+bug/1620994
[08:29] <alan_g> duflu: timing out just now. Will try again later
[08:29]  * duflu is glad that's not a geographical failure
[08:50] <duflu> Saviq: Are you confident it's just Mir missing a rebuild against protobuf3? https://bugs.launchpad.net/ubuntu/+source/mir/+bug/1621746
[08:51] <Saviq> duflu, I just meant that was a requirement, didn't know whether it was enough
[08:52] <duflu> Saviq: OK well I believe alan_g already released the protobuf fix that we were waiting on
[08:52] <duflu> Just need the powers that be to rebuild
[08:52] <duflu> Who/wherever they are
[08:54] <alan_g> Saviq: duflu I gave doko a patchfile. AFAIK everything was fine after that
[08:54] <duflu> alan_g: It got released a while ago according to distro
[08:55] <duflu> Umm a weekago it hit proposed I mean: https://launchpad.net/ubuntu/+source/protobuf
[08:55] <duflu> Not sure *which* fix that was
[08:56] <duflu> It's a miracle. I have time to work on Xmir too
[08:56] <Saviq> duflu, it was the protobuf rebuild fix, that's in proposed for sure
[08:57] <duflu> Oh, cool
[08:57] <Saviq> 'cause we couldn't build u-s-c before
[08:57] <Saviq> now we could
[08:57] <duflu> That might be it
[13:20] <alan_g> greyback_: Did I answer your "Needs Info"? https://code.launchpad.net/~alan-griffiths/mir/placement-notification/+merge/305599
[13:22] <greyback_> alan_g: yep, no objection here
[13:22] <alan_g> kdub: can you explain what you're asking? https://code.launchpad.net/~alan-griffiths/mir/placement-notification/+merge/305599/comments/790524
[13:22] <greyback_> alan_g<EMAIL_ADDRESS><- typo in your commit message email - in case you've it set up somewhere
[13:23] <alan_g> greyback_: Oops
[13:24] <alan_g> Thanks
[13:28] <kdub> alan_g, with the second part,  I didn't see why we had to have the reference that header from the top-level directory
[13:28] <kdub> and for the 1st part, that explanation makes sense, but wasn't obvious to me from reading the headers (as my guess was incorrect)
[13:29] <NotKit> are there any specific hacks needed for hwcomposer on PowerVR MediaTek devices?
[13:30] <alan_g> kdub: so the first part is answered by -r 3706?
[13:30] <kdub> alan_g, sure
[13:31] <alan_g> For the second part, that's consistent with what we do elsewhere.
[13:32] <kdub> well, why is it needed? (might find out for myself in a minute, compiling now)
[13:35] <alan_g> A lot of IDEs (including CLion that RAOF and I use) like project headers to be mentioned in the CMakeLists.txt files. We've been adding them for the last year or so.
[13:36] <NotKit> http://pastebin.com/deuQ3VEC - logcat
[13:37] <kdub> alan_g, ah, news to me
[13:38] <kdub> alan_g, alright, lgtm then
[13:38] <alan_g> kdub: RAOF and I thought no-one would even notice, so we didn't tell anyone.
[13:40] <kdub> alan_g, yeah, I don't mind as long as it has some purpose
[13:40] <alan_g> I *think* qtcreator likes it too, but it has been too long since I started it up to be sure
[13:41] <kdub> I'm still laboring under vim
[13:41] <alan_g> I use that a fair bit too
[13:42] <alan_g> But it is really nice to have a key-combo to build and run/debug just the test you're editing
[13:43] <kdub> yes, that does sound handy
[13:45] <alan_g> There's a lot of "understanding the language" stuff it makes easy. (A lot of textual manipulation stuff sends me back to vim)
[13:47] <kdub> yeah, will give it a try
[13:47] <kdub> there's only so many vim scripts one wants to write
[13:58] <anpok> did notice .. and thought - oh so visual studio isnt the only ide that needs that..
[14:03] <alan_g> attente: do you want to discuss further? Or shall we land this version? https://code.launchpad.net/~alan-griffiths/mir/placement-notification/+merge/305599
[14:05] <attente> alan_g: yeah. sorry, i didn't see the follow up
[14:44] <alan_g> attente: are you content with the current proposal?
[14:45] <attente> alan_g: how amenable is it to change? i still want the extra intermediate rectangle, so it would only be an api addition from here
[14:47] <alan_g> attente: adding another rectangle (and query for it) wouldn't break ABI. But I don't know what to put in it.
[14:47] <alan_g> So I guess we can land and discuss further
[14:49] <attente> alan_g: sounds reasonable, thanks. if you land it, i'll see if it's sufficient enough for gtk to infer the information it needs
[14:52] <alan_g> attente: OK. Meantime I can start adding in the "anchor to surface" constraints.


[04:28] <crimsun> Camden: the first two URLs in the topic are most relevant
[04:28] <crimsun> http://wiki.ubuntu.com/BugSquad and http://wiki.ubuntu.com/HelpingWithBugs
[04:29] <Camden> what exactly is an "ubuntu bug"?
[04:29] <Camden> wouldn't the bug be in some project
[04:29] <Camden> ?
[04:30] <crimsun> Ubuntu bugs are ones in Ubuntu releases and the current development version
[04:30] <crimsun> yes, some bugs are also in the upstream project's version(s)
[04:30] <Camden> what's an example of a bug, that's NOT in the upstream project?
[04:30] <crimsun> many times, bug triaging in Ubuntu requires coordinating supplying relevant information to upstream developers so they can fix the bugs
[04:31] <crimsun> Camden: well, one off the top of my head is bug 192888.
[04:31] <Camden> ok, so that's not exactly "fixing"
[04:31] <crimsun> Camden: sure, it can be fixing if you directly contribute to the fix
[04:31] <Camden> so that is a bug in libflashsupport right?
[04:31] <crimsun> Camden: no, it's a multifaceted bug
[04:32] <crimsun> Camden: it has, as its culprits, flashplugin-nonfree, libflashsupport, alsa-plugins, and alsa-lib
[04:32] <Camden> meaning... we're not sure where to change the code?
[04:32] <Camden> which project?
[04:32] <crimsun> no, we already know what's broken and how to fix it
[04:32] <Camden> it requires changes in multiple projects?
[04:33] <crimsun> there are "broken" parts in all four of those source packages
[04:33] <crimsun> yes
[04:33] <Camden> and all 4 need to be fixed in order to fix this "ubuntu bug"?
[04:34] <Camden> and it's possible for ubuntu to fix code in other projects, independently of those upstream projects
[04:34] <crimsun> correct
[04:34] <Camden> and just leave it as an option for them
[04:34] <crimsun> on both
[04:34] <Camden> to include the change
[04:34] <crimsun> best practice recommends that we work with upstream projects to get vetted fixes
[04:35] <crimsun> that way everyone, including other Linux distributors, benefit
[04:35] <crimsun> (and of course users of other Linux distributors)
[04:35] <Camden> so it's case by case decision whether to wait on the upstream or not?
[04:36] <Camden> and if ubuntu does not wait, doesn't that make it a fork?
[04:36] <Camden> i guess forks are normal
[04:36] <crimsun> Camden: it can be a case-by-case, yes, but generally you want to work closely with upstream
[04:37] <crimsun> Camden: and no, forks aren't made just because one distro contains a fix whereas upstream doesn't
[04:37] <Camden> i have heard of the concept of branches and trunks... i guess this is where it comes in?
[04:37] <crimsun> (or further, because one distro contains a fix that another doesn't)
[04:37] <Camden> so it's more a "branch" than a "fork"
[04:37] <Camden> ?
[04:38] <crimsun> that's a convenient way of thinking of development, generally, but it's not necessarily the case with fixing bugs
[04:38] <Camden> ok but there is a different source control "branch" for libflashsupport that belongs to ubuntu
[04:38] <Camden> right?
[04:38] <crimsun> yes, there is a "source package"
[04:39] <Camden> different than what belongs to the libflashsupport project?
[04:39] <Camden> and there are presumably ways to compare them?
[04:39] <crimsun> correct
[04:39] <crimsun> yes
[04:39] <Camden> so this is what contributed to the openssl problem?
[04:39] <Camden> debian had a different package than openssl
[04:39] <crimsun> a non-native Ubuntu source package contains the original upstream source and, separately, any modifications Ubuntu has made
[04:40] <crimsun> Camden: it is not the cause, but it certainly made it more complicated
[04:40] <Camden> what are "native" ubuntu packages
[04:40] <Camden> i guess i think of ubuntu as a collection of upstream packages
[04:41] <crimsun> upstream packages are called non-native
[04:41] <crimsun> ones that are native are developed solely in Ubuntu
[04:41] <Camden> right , but i guess i thought that is all there is
[04:41] <crimsun> for instance, upstart
[04:41] <Camden> ok
[04:42] <crimsun> it happens to be that upstart is an upstream project that is developed in Ubuntu but grew an external audience
[04:42] <Camden> is there some mechanism to "reserve" a bug to make sure no one else works on it?
[04:42] <crimsun> you can assign a bug to your Launchpad user and mark the Status accordingly
[04:43] <Camden> ah, ok
[04:43] <Camden> that makes sense
[04:43] <Camden> and any user can do that?
[04:43] <crimsun> not any user
[04:44] <Camden> which users?
[04:44] <crimsun> any user can assign a bug to him-/herself, but only members with privileges can alter the Status and/or Importance
[04:44] <crimsun> generally, members of ubuntu-bugcontrol have those privileges
[04:44] <crimsun> you'll want to read http://wiki.ubuntu.com/BugSquad and http://wiki.ubuntu.com/HelpingWithBugs, as I mentioned prior
[04:45] <Camden> ok
[04:45] <Camden> is there a way to locate bugs that don't involve a big learning curve to grok all the dependencies?
[04:47] <crimsun> sure
[04:47] <crimsun> there are ones tagged "bitesize"
[04:49] <Camden> cool
[04:49] <Camden> sounds like something to try
[04:50] <Camden> definitely would want to have the experience of coding something that made it into a distro
[04:50] <Camden> even if i don't take it further than that
[04:50] <Camden> but of course... could be it would lead to something
[04:50] <crimsun> yep
[04:51] <Camden> i saw an interesting article about the advantage of working on OS
[04:51] <Camden> say, you are job hunting and you've only worked in proprietery stuff
[04:51] <Camden> all you have is your word
[04:51] <Camden> you can say "i was the main developer for microsoft excel"
[04:52] <Camden> and you may not be able to prove it
[04:52] <Camden> but if you work in OS, you can just point to all your work
[04:53] <Camden> anyway whatever
[04:53] <Camden> i'll check those links
[07:34] <lifeless> meh
[07:34] <lifeless> I hate 'pleae add data' questions
[07:34] <lifeless> particularly when the bug report *has enough information already* and the folk trying to help out don't have enough.
[07:40] <Hobbsee> lifeless: help educate the triagers :)
[07:42] <lifeless> well
[07:42] <lifeless> _how_
[07:43] <lifeless> bug 44678 for instance is the most recent case
[07:44] <greg-g> yeah, the first should have checked themselves while the second was just autopilot :)
[07:46] <lifeless> :)
[07:47] <greg-g> if anyone has any suggestions on how to help educate the triagers it might help
[07:48] <greg-g> like a "rate this request for information" button ;)
[07:48] <lifeless> so the first one I meant to reply to, but was on sprint
[07:48] <lifeless> and things get real lossy on sprint
[07:48] <greg-g> yeah
[07:48] <lifeless> or  I would have mailed back a clear statement to them
[07:48] <lifeless> I just got reminded on the second occurence
[07:49] <lifeless> I think basically its a matter of them remembering that they are not machines; they need to look and think all the time
[07:49] <Hobbsee> lifeless: ah yes, that sort of thing is often a problem.
[07:50] <Hobbsee> lifeless: somewhere along the line, triaging changed from "lets try to reproduce this bug, and then deal with it" to "lets ask the reporter if they can reproduce, as it's probably a wihle ago, and then deal with it"
[07:50]  * greg-g nods
[07:50] <lifeless> well
[07:51] <lifeless> I think there is a fair concern that bugs are fixed and we have stale reports
[07:51] <lifeless> but auto-pinging is something for a cron script
[07:51] <lifeless> having a huge bug database is only _wrong_ if we don't have that many bugs
[07:52] <Hobbsee> i wonder abuot an auto-cron script.
[07:52] <greg-g> for the incomplete/no response ones?
[07:52] <lifeless> API's will be here soon
[07:52] <lifeless> you can do that then :P
[07:52] <Hobbsee> for ones that havent been responded to in a while.
[07:53] <greg-g> right
[08:04] <Rocket2DMn> ive actually been working on these ancient incomplete bugs
[08:04] <Rocket2DMn> been closing many of them
[08:07] <Hobbsee> OTOH, i think there would be merit in saying "okay, a person in $team_of_people_who_are_known_to_have_a_clue, can set their own bugs to triaged"
[08:07] <Hobbsee> and keeping on bumping the rest through the cron job.
[08:10] <greg-g> Hobbsee: people who have a clue can set their own as triaged now right?  As in, there is no technological barrier in LP, just an accepted habit.
[08:10] <greg-g> (or maybe I just never tried myself and thus not seen that I can't set my own bugs as triaged)
[08:11] <Hobbsee> greg-g: correct.
[08:43] <lifeless> Rocket2DMn: well, if you closed the bug I referenced above - it wasn't incomplete
[08:44] <Rocket2DMn> lifeless, i got the email update, thanks
[08:44] <Rocket2DMn> basically just cleaning out shop, and you hadnt responded to the other triager's request to confirm that it still existed.  Basically assumed you had abandoned the bug
[08:45] <lifeless> its not your fault, but there is a bit of an ostrich problem with closing bug reports simply because they are old - it may just mean the bug is old, and there may well be enough data to reproduce already *even if the user is no longer interested*
[08:45] <lifeless> Rocket2DMn: the other triager was lazy/ignorant/something - all the information needed to check was in the report already
[08:46] <Rocket2DMn> fair enough
[08:46] <lifeless> I *try* to file complete bugs - I file far too many to be retesting them myself everytime Ubuntu releases and they 'might' be fixed.
[08:47] <Rocket2DMn> yeah i understand
[08:58] <pwnguin> i only file bugs i care about
[08:59] <pwnguin> if i dont care enough to retest, it probably merits a "low" status anyways
[09:27] <lifeless> pwnguin: I do care about the bugs; its volume. Remember - all software sucks, its just that some sucks less than others.
[09:33] <persia> Well, some for some software, we don't know how much it sucks, which makes it harder to fix
[09:33] <persia> s/some/and/1
[11:29] <seb128> james_w: don't mark a task invalid to open a new one, change the product directly rather
[11:30] <seb128> james_w: in the gnome-control-center case it means the gnome-control-center subscribers will still get the comments on the bug
[11:42] <james_w> seb128: sorry
[11:44] <seb128> james_w: no need to be sorry, just to know for the next time ;-)
[11:44] <james_w> heh :-)
[11:45] <seb128> that could somewhat be considered as a launchpad bug
[11:46] <seb128> though you might still be interested to get comments in such cases
[11:49] <persia> I suspect it's one of the side effects of bug 225585 or something related
[11:50] <seb128> persia: the issue is to know if invalidating a task means you don't want to get new comments about it
[11:51] <seb128> in the case where you close the bug because the submitter didn't reply questions or provide enough details you might want to receive new comments
[11:51] <persia> seb128: Right.  In siretart's recent mail about LP features for LP 3.0, the set of subscription issues was called "/IgnoreSubscriptionsRevenge".  There's a few related use cases that aren't ideal now.
[11:51] <seb128> but in the same where the bug has just nothing to do there that's different
[11:52] <seb128> what is lacking now in my opinion is the ability to delete as task
[11:52] <persia> Right.  I think "Invalid" often means one should still be subscribed, but currently there's no means to unsubscribe implicit subscribers (either individually or as a team), which causes some of the issues with larger task lists.
[11:53] <persia> Task deletion sounds like a possible solution.  Hmmm..
[11:54] <seb128> 225585 would be fixed if you could delete the task, which would unsubscribe the corresponding subscribers
[11:56] <persia> seb128: Yep.  There are a few solutions.
[12:01] <Syntux> Good day
[12:01] <Syntux> What should we do in bugs that's marked as Triaged but someone uploaded a patch or it was discussed and found as upstream bug ?
[12:02] <persia> Syntux: Nothing?
[12:02] <persia> Well, you could check the status of the patch or upstream bug, and see if it has been applied to Ubuntu.
[12:02] <persia> You might also try to integrate the upstream fix or patch into Ubuntu.
[12:03] <Syntux> hmm
[12:03] <Syntux> I see
[12:03] <persia> Syntux: Essentially bugs in that state are ready for someone (upstream or developer) to do something with them to apply the fix.  There's usually not much more to triage.
[12:05] <Syntux> persia, shouldn't we change it into confirmed when someone uploads a patch ?
[12:05] <persia> Syntux: Not if it's already "Triaged".
[12:06] <persia> As I understand it (and there are other views), "Confirmed" means essentially "This is really a bug", and "Triaged" means "This bug is understood and needs a solution prepared".
[12:07] <Syntux> that's exactly what I'm saying,  a triaged bug with a prepared solution should have different status
[12:08] <Syntux> there should be a way to distinguish between triaged bugs (bugs that is understood and needs a prepared solution) and triaged bugs that someone submitted that prepared solution
[12:10] <Syntux> I'm missing something here?
[12:13] <persia> Syntux: You and I have different definitions of "prepared solution".
[12:14] <Syntux> persia, it's not about us my friend :-) can you help me in understanding bugs team definition or prepared solution ?
[12:15] <persia> For me, a prepared solution is one of 1) A developer has a fix locally and uploads it (which sets the bug to "Fix Released" when completed, 2) Upstream has integrated a solution (which sets the upstream task to "Fix Released" and adds the bugs to the list of those "Fixed Elsewhere", or 3) Someone attaches a debdiff integrating the solution (in which case the sponsors queue should be subscribed)
[12:16] <persia> Well, since "prepared solution" was my language for my personal view of the definitions of the status values, it is about us :)
[12:16] <persia> For an official definition, read the wiki pages linked in the /topic
[12:17] <persia> Anyway, I don't think bugs should go from "Triaged" to "Confirmed" unless there is some new doubt cast upon the understanding of the bug (which is the opposite of that implied by a patch or an upstream fix)
[12:17] <Syntux> maybe should go from Triaged to In Progress.
[12:19] <persia> No.  "In Progress" should only be set when someone is assigned and actually working on it.
[12:20] <persia> Leaving it alone is probably best: there are lots of other bugs.
[12:22] <Syntux> if someone submitted a patch it means s/he should be assigned
[12:22] <Syntux> it's not about a single bug, the thing is I'm hunting for small bugs so I can work on them but many of these bugs status should be changed to tell that someone has already submitted a patch
[12:24] <afflux> morning
[12:24] <afflux> Syntux: why should someone be assigned to a bug *after* submitting a patch?
[12:24] <persia> Syntux: No.  When someone is assigned, nobody else should work on it.  If someone submits a patch it is usually because they can't get any further towards fixing it themselves, and the bug now needs someone else to take over.
[12:25] <Syntux> afflux, I'm not proposing I'm asking what should the bug status be if someone submitted a patch.
[12:25] <persia> Syntux: "Confirmed" or "Triaged", depending.
[12:25] <afflux> ah, maybe I got you wrong. persia is right, triaged is correct in most cases.
[12:35] <pwnguin> is there a "how to forward bugs to debian" wiki page?
[12:37] <afflux> pwnguin: https://wiki.ubuntu.com/Bugs/ReportingToDebian and https://wiki.ubuntu.com/Bugs/Debian/Usertagging may be what you want
[12:43] <pwnguin> thanks
[12:55] <pwnguin> hmm. reportbug doesn't seem able to connect to bugs.debian.org via SMTP
[13:57] <qense> hello
[13:59] <nhandler> Hi qense
[14:26] <bddebian> Boo
[17:29] <mcas> hiho
[18:37] <mcas> can sameone please look at bug 254673
[18:38] <mcas> i am not sure if this is invalid or wishlist
[18:40] <techno_freak> mcas, looks more like an UI issue
[18:40] <mcas> UI?
[18:41] <techno_freak> err.. sorry
[18:41] <bdmurray> mcas: Why might it be Invalid?
[18:41] <techno_freak> it is not invalid, imho, as it makes sense
[18:41] <mcas> ok
[18:42] <mcas> do you have the rights to mark it as wishlist?
[18:42] <mcas> and confirmed
[18:43] <techno_freak> mcas, you can confirm it if yourself :)
[18:43] <bdmurray> It'd also be useful to tag it as string-fix as this is a simple dialog fix
[18:43] <techno_freak> s/if//
[18:43] <mcas> yes i can confirm this but i cannot change the importance
[18:44] <mcas> ok thanks bdmurray i will tag it
[18:46] <mcas> done
[18:51] <bdmurray> mvo: ping
[19:12] <mcas> bdmurray: was it wrong to confirm the bug about the adept message?
[19:12] <bdmurray> mcas: checking if it still existed in intrepid would have been ideal
[19:13] <mcas> ah ok thanks bdmurray
[23:39] <cisco_> hi!
[23:39] <nhandler> Hi cisco_
[23:49] <cisco_> I'm member and manager of PuertoRicoTeam, and we want to join on the next bugjam day
[23:49] <james_w> cisco_: hey! the one this weekend?
[23:49] <cisco_> yes
[23:49] <cisco_> should we do something?
[23:49] <cisco_> you know
[23:49] <cisco_> like
[23:50] <cisco_> subscribe the team or something like that?
[23:50] <james_w> there's a wiki page you can put your team on, I don't know if there are any other requirements.
[23:50] <ogra> fix bugs probably ?
[23:50] <ogra> :)
[23:50] <cisco_> yep
[23:50] <cisco_> I already red that,,, but should we subscribe the Team>
[23:50] <cisco_> ?
[23:51] <cisco_> for appear in the wiki...
[23:52] <james_w> cisco_: you've seen https://wiki.ubuntu.com/GlobalBugJam ?
[23:52] <james_w> you can put your team on the list there
[23:53] <cisco_> ok...I just wanted to be sure...
[23:53] <cisco_> thanks


[04:06] <Omnifrog|laptop> https://plus.google.com/hangouts/_/29bd2a3fc8fded30f4812ec1a68a9f460421f50a?authuser=0&hl=en
[04:10] <Unit193> Wrong window?
[04:10] <Omnifrog|laptop> no, feel free to join
[04:11] <Unit193> Bit in a quiet (or die) time here. :P


[01:01] <LjL> so uhm. i don't know if i should make a last attempt to settle this in a less than either abrupt or protocollar manner
[01:02] <LjL> i will anyway. phunyguy, do you not at all see your actions as possibly an unwarranted attack on me in #u-o?
[01:02] <bazhang> hi LjL
[01:03] <bazhang> missed you buddy
[01:03] <LjL> and IdleOne, do you not at all appreciate how a consistent requiring one party to "behave" and not the same of other, more in-power, parties (or only when pointed out) as provoking?
[01:03] <LjL> bazhang, there are techniques to improve your aim.
[01:08] <phunyguy> LjL: I said the first thing, about grudges, etc, but that was meant as a joke.  I am sorry if you got offended. I really do sincerely wish you were back in the channels as you, and it wasn't a personal attack.
[01:08] <phunyguy> I thought it had been long enough that we could kind of put it behind us.
[01:13] <LjL> phunyguy, i have the logs of what was said in front of me. i made a joke where i said erec was petty (and despite you perhaps having your reasons to think i was also calling you petty, i factually wasn't), and you went, "Look, until you stop hiding behind a nick, keep quiet."
[01:13] <LjL> is that something about grudges that was meant as a joke? do you think it could have been an honest step to bring me back in the channels?
[01:14] <phunyguy> [19:42:34] <A_bee> it's NOT THE PROCEDURE  <--- this was actually first.
[01:14] <phunyguy> If you want to get factual.
[01:14] <LjL> that was ages before it.
[01:15] <LjL> but i see you're wanting to get this... procedural indeed.
[01:15] <phunyguy> [19:50:57] <phunyguy> why isn't the other you here?
[01:15] <phunyguy> [19:51:08] <phunyguy> :<
[01:15] <phunyguy> that was sincere
[01:15] <phunyguy> not me being a turd.
[01:16] <phunyguy> and the "procedural" is all you.  You joined this channel to talk about it... we are talking about it.
[01:16] <LjL> phunyguy: i can accept that. but could we please concentrate on the escalation of things that happened before i nicked back to LjL`? because if you want to go back ages into logs, i can do that too, but it'd just murk waters.
[01:16] <phunyguy> I just want you to not be offended at every thing everyone says.
[01:16] <LjL> okay, should you prefer that we talk about this in another venue or manner?
[01:21] <phunyguy> I think here is fine.  I am sorry for reacting the way I did.  I didn't realize what I said hit you that way.
[01:23] <LjL> phunyguy: do you see the following reading of what happened as roughly accurate? i made a joke involving #ubuntu, you and erec, involving the word "petty", that you interpreted badly (because you already though i think you're petty? i guess) - so since you haven't accepted the fact i usually join #u-o now as the A_bee alter ego, instead of LjL, you told me i should stop speaking unless i could stop "hiding" behind that nickname, in a somewhat resentful
[01:23] <LjL> manner - then i called you "butthurt", and you called me an "asshole", and IdleOne intervened
[01:24] <phunyguy> Oh good grief
[01:25] <phunyguy> You really think what you said wasn't directed at me?     If any IRC Council member, or other ops, are willing to chime in with opinions now, i will be around for some more minutes to listen.
[01:31] <LjL> I also should point out that since IdleOne doesn't seem to be around now, I haven't discussed his intervention after the incident with phunyguy, but I will also discuss that later with the IRC Council because I'm unhappy with how that was handled.
[03:33] <IdleOne> For the record. I asked A_bee to please stop first because the first thing I saw was him calling phunyguy names. I didn't have a chance to ask phunyguy before A_bee pointed out that I had not. Second of all, I have no problem kicking or even banning a fellow op if it is needed and phunyguy is aware of that. I asked them both to stop or I would kick them both.
[03:33] <IdleOne> from what I can see in my scroll back it did stop.
[03:34] <IdleOne> although my client bugs out sometimes and I lose bits and bites
[16:49] <bazhang> @random manjaro HURD
[16:49] <bazhang> ok then
[16:50] <bazhang> manjaro spammer hitting #ubuntu
[16:50] <bazhang> the nerve
[16:50] <chu> <3 HURD
[16:50] <bazhang> you got emacs in my HURD
[16:50] <chu> :D
[16:50] <bazhang> two great tastes!
[16:50] <k1l> it hurds so much
[16:51] <bazhang> ouch!
[16:51] <bazhang> reeses cups reference above
[16:51] <chu> lol
[17:50] <bazhang> down 2pts!


[21:13] <ryan___> I'm having a problem
[21:14] <ryan___> & I never knw that Wales had an Ubuntu IRC :O
[21:14] <ryan___> Anyways here is my error: E: Sub-process /usr/bin/dpkg returned an error code (1)


[01:14] <micahg> jtaylor: I don't mind rebuilding imagemagick, what's being dropped?
[01:15] <micahg> jtaylor: nevermind, I can use tools to figure it out
[01:18] <micahg> jtaylor: only edubuntu and ubuntustudio seems to be affected (well, mythbuntu also, but they're not releasing ISOs)
[07:49] <dholbach> good morning
[08:13] <dholbach> debfx, directhex, DktrKranz: could one of you imagine teaming up with bdrung for the Developers Roundtable at UDW (Thu 31st Jan, 19:00 UTC), which will mostly be a Q&A session where everybody can ask their questions about Ubuntu Development in general?
[08:37] <iulian> Morning dholbach.
[08:37] <dholbach> hey iulian
[08:37] <dholbach> iulian, ^ maybe you could be interested in joining bdrung? :)
[08:38] <iulian> Nop, can't do that unfortunately. :(
[08:39] <dholbach> no worries, I hope we find somebody else
[08:39] <iulian> I'm sure there's someone out there with more free time than me. ;)
[08:40] <dholbach> there's 18:30 UTC (30m session) on that day we still have to find a speaker for too - we were thinking of either a demo of fixing a small bug or a walk through a few places to check for stuff to work on
[09:54] <Rhonda> *sigh*
[09:54] <Rhonda> People mail me that the packages.ubuntu.com site uses the old favicon - but noone tells me where to get the new one.
[09:54] <Rhonda> And strangely, chrome doesn't display it to me on the www.ubuntu.com neither.
[09:55] <tumbleweed> I see it in FF
[09:55] <Rhonda> Or on www.debian.org  *puzzled*
[09:55] <tumbleweed> www.ubuntu.com/sites/all/themes/ubuntu10/favicon.ico according to the source
[09:55] <Rhonda> Yep, found it in the source.
[09:56] <Rhonda> But it's still a bit … well.  *sigh* :)
[10:35] <MCR1> notgary: Hi :) If you are still searching for bitesize Compiz bugs for papercutters, here is quite a bunch of those: https://bugs.launchpad.net/compiz/+bugs?field.tag=coverity
[10:36] <MCR1> notgary: They seem to be ideal for newbies, because the whole sourcecode is Coverity commented and pretty self-explainatory, but ofc there might be false positives among those as well...
[10:39] <MCR1> notgary: This was just FYI, if you want to concentrate on other projects first, then no problem either - but feel free to use those, if you are on papercutters-bug-shortage ;)
[10:47] <MCR1> dholbach: Hi :) How many contributions to Ubuntu does one have to make until a packaging wish gets fulfilled for free ;) ?
[10:49] <MCR1> dholbach: I am missing https://bugs.launchpad.net/ubuntu/+source/emerald/+bug/968112 :)
[11:47] <xnox> MCR1: made a comment on the bug. Please provide requested information (it's mostly treasure-hunt / google-foo) =)
[12:55] <MCR1> xnox: This was not the solution I expected. Please read https://bugs.launchpad.net/ubuntu/+source/emerald/+bug/968112/comments/7
[12:56] <MCR1> xnox: I am running Emerald on Raring with latest Compiz/Unity and did so on Precise and Quantal as well
[12:59] <ogra_> MCR1, the point is that there will be nobody fixing bugs, the code was put to death by its developers
[13:00] <ogra_> so even if it builds and runs on all supported arches (which i highly doubt for arm or powerpc), it would just rot in the archive
[13:01] <MCR1> ogra_: Has every program for Ubuntu now to run on the Ubuntu phone ?
[13:01] <ogra_> ??
[13:01] <MCR1> ogra_: Then you would have to remove a lot more packages from the repos...
[13:01] <ogra_> no, the phoine wont run most apps, it doesnt run an X server afaik
[13:02] <ogra_> what has the phone to do with it ?
[13:04] <MCR1> ogra_: The point is: there is currently no replacement equal to or even better than Emerald and it still works, so why throw it out ?
[13:04] <ogra_> because its developers consider it dead
[13:04] <ogra_> and it diodnt build on all arches ... since there was no developer for fixing it, it had to be removed from the archive
[13:05] <MCR1> well, I would fix potential problems...
[13:06] <ogra_> so first make sure to have the FTBFS fixed then
[13:06] <MCR1> the build log from the bug is from a wrong version of Emerald btw - seems to be the non C++ branch
[13:07] <MCR1> well, as I told you: I can build it without problems
[13:07] <ogra_> create a PPA, ask the launchpad team for powerpc and armhf support for it, make sure it builds in all arches
[13:08] <ogra_> alternatively just convince debian to ship it and it will automatically be synced from there
[13:08] <ogra_> but its very unlikely debian will allow it in if it is an abandoned project upstream
[13:09] <tumbleweed> (and of course you'd get push-back in Ubuntu for that too)
[13:10]  * ogra_ wouldnt push back if someone can actually proof he can take over upstream fixing and packaging for all arches and bugs
[13:10] <tumbleweed> in which case, it should totally be in Debian :)
[13:10] <ogra_> but thats indeed a quite advanced and likely also time consuming full time job :)
[13:11] <MCR1> okay, guess I'll try to chat with some of the Debian packagers then - thanks
[13:11] <tumbleweed> if there were historically problems buildign it on other archs
[13:11] <ogra_> i bet they will tell you the same, but good luck
[13:11] <tumbleweed> I'd start by seeinf if those are still issues
[13:11] <tumbleweed> it's easy enough to build for ARM with qemu
[13:11] <ogra_> right, thats why i suggested a PPA
[13:12] <MCR1> tumbleweed: The initial problem was just a linker error
[13:12] <ogra_> now that you can have armhf ...
[13:12] <MCR1> then it got removed
[13:13] <ogra_> it didnt build and nobody wanted to fix it
[13:13] <MCR1> it was working and available until 11.10 and first noone knew how to fix it
[13:13] <ogra_> (note that between opening of the bug and removing the package there were 6 weeks)
[13:14] <ogra_> nobody bothered to fix it and there was no upstream anymore ... we dont allow packages in the archive that dont build
[13:14] <tumbleweed> we have hundreds of packages that fail to build, each release. The few people that care don't have time to fix them all
[13:14] <ogra_> right
[13:14] <MCR1> then someone found out how to fix it and I added this information, but later nothing happened
[13:15] <ogra_> and what cant be fixed and has no chance to be fixed through upstreams will be removed
[13:15] <tumbleweed> because if we bring it back - there's still no upstream, so it's just a matter of time before it breaks again, and we have to deal with it
[13:15] <ogra_> MCR1, ?? i dont see any other comment in the bug
[13:15] <MCR1> all I am asking you is helping me get this package back in as I am no packager and have no packaging skills
[13:16] <ogra_> doko obviously opened it on 2011-08-22 ... there were no comments on it until the package was removed 6 weeks later
[13:16] <ogra_> MCR1, well, that can only happen if someone fixes it
[13:16] <MCR1> ogra_: You are right -> it took some time until we found out the fix for the failing compilation
[13:17] <ogra_> MCR1, the last comment on the bug is from 2011-09-29
[13:17] <ogra_> and there were no further ones until you commented a few mins ago
[13:17] <MCR1> ogra_: I've now added detailed instructions - I did not know about this bug
[13:18] <ogra_> detailed instructions ?
[13:18] <ogra_> git checkout and make dont really help
[13:18] <MCR1> ogra_: I made my own one here bug 968112
[13:18] <ogra_> someone needs to make a new upstream release of emerald, someone else needs to package it
[13:19] <ogra_> and it needs to build on all arches
[13:19] <ogra_> thats not a trivial task
[13:19] <MCR1> I have only x86
[13:19] <MCR1> :(
[13:19] <ogra_> use a PPA then
[13:19]  * ogra_ thinks we talk in circles since a while
[13:20] <MCR1> ok, thx 4 the help
[13:20] <ogra_> make it build and provide a debdiff, find an upstream dev or find a packager who is willing to take the heavylifting
[13:20] <MCR1> thx
[13:36] <MCR1> ogra_: Does it help to have a PPA for i386 and amd64 maintained builds for Precise and Quantal ?
[13:37] <MCR1> lp user ~brainpower is maintaining such a PPA, here the Quantal builds: https://launchpad.net/~brainpower/+archive/testing/+sourcepub/2745472/+listing-archive-extra
[13:39] <ogra_> well, make him build for armhf and ppc too
[13:40] <MCR1> I do not think that this will be easily possible, is this support essential ?
[13:41] <ogra_> well, you need to make sure it builds on all arches
[13:41] <tumbleweed> ogra_: AFAIK nan-canonical people can't get ppc access
[13:41] <tumbleweed> we don't have emulated ppc
[13:42] <ogra_> oh, ibthought ppc builds in containers too now
[13:42] <tumbleweed> maybe I haven't been following *that* closely
[13:42] <MCR1> ogra_: In Compiz we have plugins that are only built for amd64/i386 and won't work and thus are not compiled and packaged for arm/GLES
[13:42] <tumbleweed> but I certainly don't see ppc ppa builders
[13:43] <ogra_> well, i'm probably ahead of time here... UDS smoking corner marketingvtalks ;)
[13:43] <MCR1> ogra_: That is why I asked if all packages nowadays need to run on arm also ?
[13:43] <ogra_> MCR1, yes
[13:44] <MCR1> I bet there are a ton of exceptions for this rule
[13:44] <ogra_> not really...
[13:45] <MCR1> no more glscreensaver for example ?
[13:45] <ogra_> on hw that has no gl thats moot
[13:45] <MCR1> remove all OpenGL applications ?
[13:45] <ogra_> why ?
[13:45] <MCR1> You really must be joking now
[13:45] <ogra_> sw rendering works on arm
[13:46] <MCR1> OpenGL != GLES
[13:46] <ogra_> just not fast
[13:46] <ogra_> and ?
[13:46] <xnox> MCR1: the replacements are the gtk & kde window decorator bridges + themes.
[13:46] <ogra_> mesa = mesa ;)
[13:47] <xnox> MCR1: with respect to "solution", it simply means that it's underlinked and those two libs need to be either added at configure.ac / Makefile.am level, or potentially they are in the wrong order and need to come later.
[13:47] <ogra_> which is an upstream task
[13:47] <xnox> MCR1: with a proper patch & autoreconf, it might go into universe or something like that.
[13:48] <ogra_> right
[13:48] <xnox> ogra_: we patch a lot of packages like that =)))))
[13:48] <MCR1> xnox: that would be great news :)
[13:48] <ogra_> as i said. provide a debdiff and make sure it builds
[13:49] <ogra_> (on all arches indeed)
[13:52] <MCR1> ogra_: This is no attack, I am just wondering: http://packages.ubuntu.com/raring/xscreensaver-gl
[13:52] <MCR1> Where are the arm builds ?
[13:52] <Laney> hmm?
[13:53] <Laney> I don't think we have any hard and fast requirement about that
[13:53] <MCR1> it would be quite ugly for the repos...
[13:53] <Laney> ensuring ongoing maintenance is more interesting IME
[13:53] <ogra_> MCR1, on launchpad
[13:54] <ogra_> you use the wrong tool, packages.u.c is a third party service only listing x86 arches
[13:54] <MCR1> ah, ok
[13:56] <tumbleweed> erm, that's not entirely accurate. it's on ubuntu.com and hosted on canonical servers, we can't call it a third party service
[13:56] <tumbleweed> but yes, it builds on armhf https://launchpad.net/ubuntu/precise/armhf/xscreensaver-gl
[13:57] <ogra_> oh, ssince when ?
[13:57] <ogra_> it used to be run by abdebian guy in the past, when wasbit moved ?
[13:57] <MCR1> ogra_: I could find them on launchpad, thx 4 the info.
[13:57] <tumbleweed> as long as I've know it... And yes, it is run by Rhonda, who is more a debian person
[13:58]  * Rhonda hides
[13:58] <MCR1> ogra_: I will try my best to meet Emerald requirements (might take a while though...)
[13:58] <ogra_> hmm, i'm probably to long in this business
[13:59] <Rhonda> MCR1, arm is not part of the official pool, is it.
[13:59] <ogra_> iit is
[13:59] <Rhonda> I don't see arm in http://archive.ubuntu.com/ubuntu/dists/raring/
[13:59] <tumbleweed> and no, there is no requirement that every package build on every arch. But it's preferred.
[13:59] <ogra_> since 5 releases
[13:59] <Rhonda> ogra_, isn't
[13:59] <tumbleweed> Rhonda: it's on ports.ubuntu.com
[13:59] <Rhonda> tumbleweed: That's a seperate pool, thanks for proving my point.
[13:59] <tumbleweed> internally to LP, they are the same pool
[14:00] <Laney> can you get at an internal mirror from the packages.u.c box?
[14:00] <tumbleweed> it gets split out before it hits the primary public mirror
[14:00] <Laney> where they are in the same pool
[14:00] <ogra_> Rhonda, it is officialnsince lucid
[14:00] <Rhonda> ogra_, http://archive.ubuntu.com/ubuntu/dists/lucid/ doesn't have it neither.
[14:00] <ogra_> but will never move to archive.u.c
[14:00] <Rhonda> Thanks again for proving my point.
[14:00] <Laney> it's to do with usage not officialdom
[14:00] <ogra_> it is a 100% officially supported arch nontheless
[14:01] <Rhonda> Why isn't it in the same pool then but in ports?
[14:01] <ogra_> wejust dont move it to save mirrors from complaining,mits avtech reason we wont mobe itto archive.u.c
[14:02] <Laney> parse error
[14:02] <ogra_> sorry, typing on a nexus7 here
[14:02] <Rhonda> Me too :)
[14:02] <ogra_> we just dont move it to save mirror admins from complaining, its a tech reason we wont move it to archive.u.c
[14:03] <Rhonda> Then it's the same tech reason it's not included in pkg.u.c
[14:03] <ogra_> but itis a fully supported arch nontheless
[14:03] <ogra_> with 5 years support etc yadda yadda
[14:04] <ogra_> (LTS supported only since precise though)
[14:04] <Rhonda> If someone would like to sponsor my efforts along that lines I would be willing to invest more time into the packages code.  Unfortunately my time is limited and I have to take care for my kid and pay back loan.
[14:04] <ogra_> we all do .., sadly :/
[14:06] <tumbleweed> knowing nothing about canonical infrastructure, is there a full mirror available to it?
[14:06] <tumbleweed> full as in including ports
[14:06] <ogra_> nope
[14:06] <tumbleweed> because that would make it easy
[14:07] <ogra_> persia knows a few unofficial asian ports mirrors iirc
[14:07] <tumbleweed> yeah, it's not hard to reassemble one
[14:07] <ogra_> but beyind that there arent any officilly
[14:09] <Rhonda> tumbleweed: Well, taking everything from ports isn't something I fancy.  Are really all archs on ports officially supported ones?
[14:09] <ogra_> ppc and armhf are
[14:09] <tumbleweed> and armel went away
[14:09] <Rhonda> Hm, and those are the only two I see for raring.
[14:09] <ogra_> armel not
[14:10] <Rhonda> Was armel official in lucid?  ia64?  sparc?
[14:10] <Rhonda> Thing is, deciding which are officially supported and which are not from having all in the same pool is fishing for problems.
[14:10] <ogra_> armel, no ppc and no sparc/ia64 iirc
[14:10] <Rhonda> Would require load of additional complexity in the code.
[14:11] <Rhonda> If the official ones could be moved to archive and the inofficial be kept on ports, there would be code to work with that.
[14:11] <tumbleweed> presumably at some point, we'll have to move armhf to archive.u.c
[14:11] <tumbleweed> (or arm64 by then...)
[14:11] <ogra_> iirc there are some tools in ubuntu-dev-tools tobfind whatsnsupported
[14:11] <Rhonda> And additional complexity only for the reason "to save mirror admins from complaining"
[14:12] <Rhonda> I dislike such decisions.  They make things just unneeded complicated. :/
[14:12] <tumbleweed> ogra_: not that I know of
[14:12] <tumbleweed> (but that was supposed to happen as the next stage of reorg...)
[14:12]  * ogra_ didnt make that decision, i would love to see my arm work on a.u.c
[14:13] <tumbleweed> I assume at some point the traffic on ports will become unmanageable
[14:13] <tumbleweed> (unless all vendors do their own thing)
[14:13] <ogra_> but it has been discussed each release for the past 4 years
[14:13] <ogra_> and hasnt moved til today
[14:14] <tumbleweed> anyway, there is no requirement that every package build on every arch. But it's preferred. In Debain, I port my packages to all the archs I can
[14:14] <ogra_> so i wouldnt expectthat to happen in the near future either
[14:14] <Rhonda> The much I hate making you feel bad for your work because it doesn't receive the publicity it deserves, the much I go with the pragmatic approach here: Not working around that issue might increase the preassure on them to get it in.
[14:15] <ogra_> tumbleweed, i wouldnt let a package in if it wouldnt buildon all arches
[14:15] <ogra_> Rhonda, heh,i didnt mean to push you there :)
[14:16] <tumbleweed> ogra_: in this case, I'd agree with you
[14:16] <ogra_> i was just stating the fact that o.u.c only has x86
[14:16] <ogra_> *p.u.c
[14:21] <Rhonda> Yep.  And I've heard that before.  My plan is to activate the "debports" part for ports.u.c to include them that way.
[14:21] <Rhonda> It would show the archs on the packages lists, but explicitly state them as "(unofficial port)"
[14:22] <Rhonda> That's the best I can offer on more-or-less short term.
[14:22] <tumbleweed> being accurate about the officialness and canonical-supportability isn't that important on packages.u.c
[14:22] <tumbleweed> (to me)
[14:29] <xnox> Rhonda: armhf is official, despite living on ports.
[14:29] <xnox> Rhonda: the ports vs archive split is pure disk space management for mirrors.
[14:30] <xnox> Rhonda: just list them all, without any labels =)
[14:30] <tumbleweed> I assume that requires more work
[14:33] <Rhonda> xnox: Do you say so with your canonical hat on?  :)
[14:34] <xnox> Rhonda: yes =)
[14:35] <xnox> Rhonda: also documented here: https://wiki.ubuntu.com/SecurityTeam/FAQ#Architectures
[14:35] <xnox> Rhonda: "While ARMEL and ARMHF are listed in ports.ubuntu.com for this release, they should be considered supported architectures"
[14:36] <Rhonda> AHAH!
[14:36] <Rhonda> "maintenance is best-effort"
[14:36] <tumbleweed> see footnote 4
[14:36] <xnox> Rhonda: but i think footnote 4 overrides that =)
[14:36] <ogra_> it does
[14:37] <Rhonda> xnox: Yes, but that's a specific statement for those two archs, not a general one.
[14:37] <Rhonda> And that's where it gets tricky.
[14:37] <xnox> Rhonda: yeah, hence why I explicetly said "Rhonda: armhf is official, despite living on ports."
[14:37] <xnox> since armel is dropped in raring now anyway.
[14:38] <Rhonda> You also said "just list them all, without any labels =)"
[14:38] <ogra_> erm, the release manifest linked is outdated
[14:38] <xnox> Rhonda: list them all without goind down the path of labeling something offices vs unofficial. It gets tricky very quickly and not as clear cut as ports vs archive.
[14:38] <xnox> since some ports at some point in time have or hasn't been "official"
[14:39] <ogra_> yeah, powerpc was on and off
[14:40] <xnox> Rhonda: anyway p.u.c is very useful =) and the more it lists the better.
[14:45] <Rhonda> Well …   http://www.amazon.de/registry/wishlist/3UJMXUVWGN7Y9/   *whistlesinnocently*   ;)
[14:47] <Rhonda> No, I'll look into (ab)using the debports port for getting the ports stuff in.  And I need to look why the package descriptions are NOT appearing anymore on the site.  %-/
[14:48] <xnox> Rhonda: this seems appropriate "Getting Things Done. The Art of Stress-Free Productivity"
[14:52]  * Rhonda nods


[00:13] <kayetech> hello, I'm looking to install xubuntu from the iso without putting it on a usb drive first. is that possible?
[00:14] <knome> not in a minute...
[00:14] <genii> ..oh, they left
[00:15] <bazhang> was that the plop kid
[00:15] <genii> With grub it can be done. plop I dunno
[00:16] <bazhang> he just took it to the main channel
[00:16] <knome> i don't think plop is the tool for this one
[00:16] <knome> i've done it before myself, and it's not worth it...
[00:16] <bazhang> yeah
[00:16] <bazhang> there was a user earlier with a broken dvd drive
[00:18] <Unit193> Sometimes you can update the firmware and skip plop.
[01:16] <kayetech> hello. I just put the xubuntu 64bit iso on to a usb stick and booted to the stick. it showed the xubuntu logo briefly, then the screen went black and had a cursor blinking in the upper left and was unresponsive
[01:17] <kayetech> should I try a different iso?
[01:18] <bazhang> kayetech, please dont crosspost
[01:18] <bazhang> you are actively getting help in #ubuntu
[01:19] <kayetech> I posted here first
[01:19] <bazhang> then left
[01:19] <kayetech> and last time I posted no one responded so I went there
[01:19] <bazhang> and now you are
[01:19] <kayetech> yes, I'm sticking to that chan
[01:19] <kayetech> thanks
[07:20] <Mtrz> Is it possible to rotate a display with nomodeset ?
[08:15] <adrian____> tree
[08:21] <xubuntu85w> ==xubuntu 1
[12:46] <pmjdebruijn> hi folks
[12:50] <knome> hello
[13:19] <pmjdebruijn> any clue what package contains the xubuntu isolinux logos etc
[15:25] <pmjdebruijn> I'm trying to build a custom xubuntu iso with: ubuntu-defaults-image  --arch amd64 --flavor xubuntu --release xenial
[15:25] <pmjdebruijn> and it works just fine, except that isolinux uses ubuntu artwork as opposed xubuntu
[15:27] <pmjdebruijn> ubuntu-default-image is just a thin wrapper around live-build
[19:26] <xubuntu53w> I cant install nothing in my Xubuntu 16.04
[19:29] <pmjdebruijn> what exactly are you trying to do?
[19:31] <xubuntu53w> the packed astah professional need to be reinstalled
[19:32] <xubuntu53w> i was trying install this packed, astah professional 7.0 .deb
[19:33] <xubuntu53w> but after of insert my passwd and beging the installed this dont finish, just tried but cant finish.
[19:36] <pmjdebruijn> how are you doing to install it?
[19:36] <xubuntu53w> And if I try install other packeds like virtualbox, cant do it. Beging but cant finish.
[19:36] <pmjdebruijn> sudo dpkg -i astah_7.deb ?
[19:36] <pmjdebruijn> or just doubleclicking?
[19:36] <xubuntu53w> no I just double click in.
[19:36] <pmjdebruijn> presumably that should at least give you a clear error of what going wrong
[19:37] <pmjdebruijn> other I suggest trying from the console
[19:37] <pmjdebruijn> but keep in mind that deb files from commercial parties tend to be of lesser quality
[19:38] <xubuntu53w> ok, i will try it from the console.
[19:41] <pmjdebruijn> and?
[19:41] <pmjdebruijn> you might need to run sudo apt-get install -f afterwards, to satisfy any dependancies
[19:42] <xubuntu53w> dont work but a have an error number 1
[19:42] <xubuntu53w> dont work but I have an error: number 1
[19:43] <genii> Thats not extremely useful
[19:43] <pmjdebruijn> usually there's some text as well
[19:44] <pmjdebruijn> can you put the entire output of the 'sudo dpkg -i my.deb' command on pastebin.com ?
[19:44] <genii> Can you use a pastebin website to copy all the text in the console from when you typed in the dpkg -i command to when it returned to a command prompt, and provide us with the URL
[19:44]  * genii makes more coffee and semi-wanders back to work
[19:45] <pmjdebruijn> also what does 'file my.deb' say
[19:45] <pmjdebruijn> does it confirm it's a debian package
[19:45] <pmjdebruijn> and not a failed/corrupted download?
[19:46] <genii> ...is your console in the dir where the deb file is? are you providing the actual name of the deb file?
[19:48] <xubuntu53w> no Im not in the dir when i execute the .deb i will tried
[19:52] <xubuntu53w> Ok i execute in the dir and i can see this message:
[19:53] <xubuntu53w> I need install a JDK 8 update 45 o later and after execute: #astah-pro i will try this
[19:54] <genii> !info openjdk-8-jdk xenial
[19:55] <genii> hm
[19:59] <xubuntu53w> but is for 64 bits, i need ofr 32
[20:03] <xubuntu53w> Sorry for all im a rookie xubuntu... thank you for the time!
[21:35] <slickymasterWork> good you're around
[21:36] <slickymasterWork> I wanted to ask you something
[21:36] <knome> slickymasterWork, me?
[21:36] <knome> is this the right channel though?
[21:36] <knome> (:
[21:36] <slickymasterWork> right
[21:36] <slickymasterWork> probably not
[23:25] <tobiasBora> Hello,
[23:26] <tobiasBora> I love the xubuntu theme, but I'd like to adapt it to another distribution (debian) which has the defaults xfce themes. What are the modifications made to the original theme that would allow me to have the beautifull xubuntu theme ?
[23:37] <knome> tobiasBora, greybird-gtk-theme is available in stretch and sid
[23:42] <tobiasBora> knome: Ok thank you, I'm updating to stretch.
[23:42] <tobiasBora> knome: And for the icons it's elementary right ?
[23:42] <knome> elementary-xfce, but yes
[23:42] <Unit193> Not in Debian last I knew.
[23:53] <tobiasBora> So I need to manually insstall it right?
[23:57] <Unit193> Defaults still won't be the same either way.  There's actually already an ISO that's done pretty much what I think you're looking for.
[23:58] <tobiasBora> You mean that xubuntu uses it's own version of elementary-xfce ?


[05:04] <Researcher-> Hello good morning everyone.
[05:04] <Researcher-> :)
[06:27] <Shani> hello everyone.
[06:27] <Shani> Good morning
[06:29] <Kilos> hi Shani
[06:31] <Shani> hi Kilos
[06:31] <Shani> how are you bro
[08:10] <Researcher-> hi zaki
[08:10] <Researcher-> wb
[08:10] <GodMother> hello all
[08:10] <GodMother> like to chat ?
[08:10] <Researcher-> hmm
[08:10] <Researcher-> yes but your nick .. mmmm
[08:10] <Researcher-> its ok
[08:10] <GodMother> what my nick ?
[08:11] <GodMother> if GodFathers can exsist why not GodMothers ?
[08:11] <Researcher-> ohhhh
[08:11] <Researcher-> agree you,
[08:11] <Researcher-> seems like you related to sandact mafia underworld ?
[08:11] <Researcher-> right
[08:11] <GodMother> hehehe
[08:11] <GodMother> yeah me be
[08:11] <GodMother> :)
[08:11] <GodMother> ill pm you wait.
[08:11] <Researcher-> ahan ok
[08:51] <lubmil> dzień
[11:17] <Researcher-> hello everyone
[11:17] <Researcher-> :)
[11:17] <Researcher-> how are you all.
[11:19] <Researcher-> One of the long time opensource and ubuntu contributor, Miles Sharpe (IRC NICK : Kilos) need your help and donations, please read the full story and help him, https://www.gofundme.com/reunionroadblock