Log of the #sugar IRC Channel

All the times shown here presently are in Boston Standard Time -0500Hrs

Date : 13-04-2015

[06:17:46] [connected at Mon Apr 13 06:17:46 2015]
[06:17:46] <asimov.freenode.net> *** Looking up your hostname...
[06:17:46] <asimov.freenode.net> *** Checking Ident
[06:17:46] <asimov.freenode.net> *** Got Ident response
[06:17:46] <asimov.freenode.net> *** Found your hostname
[06:17:47] <NickServ> NOTignacio is not a registered nickname.
[06:17:52] [I have joined #sugar]
[06:18:14] <jo0nas> hi santiago_
[06:19:25] <santiago> hey jo0nas!
[06:19:38] <jo0nas> where are you? France?
[06:20:29] <santiago> yes, I'm in France
[06:20:34] <santiago> great to hear from you!
[06:20:51] <jo0nas> likewise!
[06:22:29] <santiago> I was just reading your mail and about bug #782414
[06:22:43] <jo0nas> good
[06:23:24] <jo0nas> quite frustrating - but then again, it indicates noone has really used the Debian Sugar packaging for a while
[06:24:24] <jo0nas> Tubes-based collaboration has been broken since August 2013!
[06:24:29] <santiago> and worse, none has really used, at least as it is aimed to be used
[06:25:29] <jo0nas> do you agree with my plan to simply request ftpmaster removal of *all* Sugar packages from Jessie suite?
[06:25:52] <jo0nas> ...or do you need time to think more about it, perhaps?
[06:26:24] * jo0nas is very happy to get hold of santiago to not take the decision alone
[06:26:29] <santiago> hehehe
[06:27:04] <santiago> current sugar in jessie is half sugar
[06:27:09] <jo0nas> I am lousy at collaboration, far better at working alone
[06:27:52] <jo0nas> think is, packaging of Sugar 0.98 is in bad shape even ignoring that Tubes issue
[06:28:40] <jo0nas> have a look at current git and see my recent commits that has "Fix" in it
[06:28:41] <santiago> (I'm worse collaborating, I'd decide relying on the users :P)
[06:30:01] <jo0nas> it was great that you pushed 0.98 1.5 years ago, but seems you didn't look at how the code had changed: apparently you didn't adapt the package relations at all
[06:30:02] <santiago> anyway, I think you're right. And maybe the best thing to do is to maintain Sugar in jessie-backport
[06:30:34] <jo0nas> I don't use backport.debian.org - feel free to do it
[06:32:08] <jo0nas> fine - then I file a request for dropping Sugar for Jessie
[06:32:14] <santiago> ok
[06:32:37] <jo0nas> are you busy nowadays? Time to help with packaging?
[06:33:24] <jo0nas> ...and with guiding others in packaging?
[06:34:05] <santiago> I'm quite busy, at least for the next two weeks, I think won't have the time to work on packaging by myself, but I can help guiding if needed
[06:34:09] <jo0nas> Quozl` and tcl have shown interest in learning to package for Debian - and icarito too
[06:34:20] <jo0nas> ok
[06:34:29] <santiago> great!
[06:35:24] <jo0nas> browse and chat activities are up-to-date and good reference packagings for modern GTK3 acitivites
[06:36:19] <jo0nas> libraries for GTK2 activities need to be updated - so I recommend avoiding GTK2 activities at first
[06:36:56] <jo0nas> I hope to have GTK2 libraries updated in a day or two
[06:37:51] <jo0nas> santiago: nice if you can help Quozl` icarito and tcl with packaging GTK3 activites - and then later GTK2 ones too
[06:38:50] <jo0nas> I recommend to use chat and browse as examples - but then package not-yet-in-Debian activities instead of updating ones already in Debian
[06:39:26] <santiago> jo0nas, ok! with pleasure
[06:39:27] <jo0nas> I guess it is more confusing than helpful to look at existing packages - needs understanding of old quirks and workarounds
[06:40:01] <jo0nas> s/existing packages/existing activities apart from browse and chat/
[06:49:26] <santiago> I have to go now.
[06:51:54] <santiago> thanks for all your work again!
[08:37:31] <tch__> jo0nas, good morning
[08:38:14] <tch__> jo0nas, I saw your reply, keep mind this affects Jabber collaboration, but local-link collaboration is still working
[08:39:14] <tch__> jo0nas, and many activities on sugar does not use collaboration, even having these other activities on "solo" mode is a huge benefit in the educational ground :)
[08:40:52] <icarito> tch__, jo0nas, i think sugar is broken in current jessie in a number of ways
[08:40:58] <icarito> tch__, most activities don't start
[08:41:11] <icarito> so I think jo0nas is right to not ship a broken sugar
[08:41:19] <icarito> unless I'm wrong and 0.98 works well
[08:41:27] <icarito> maybe I missed something
[08:41:51] <icarito> let me know if you need me to test 0.98 on jessie and file more bugs
[08:47:31] <tch__> icarito, its his call of course :) I am just clarifying
[09:22:50] <icarito> bernie, do we have a voting machine?
[09:22:55] <icarito> i.e. a vm or something?
[09:23:12] * icarito is still waiting to access to the members list
[09:25:52] * icarito makes chocolate for breakfast
[09:26:27] <tch__> icarito, sounds good, send some to .py ;)
[09:27:20] <icarito> lo mejor de colombia es que es tradición tomar chocolate al desayuno :-D
[09:28:02] <icarito> i mean
[09:28:12] <meeting> The best of *colombia is that it is tradition take chocolate to the breakfast
[09:28:19] <icarito> :-D
[09:28:23] <tch__> icarito, jajaj,
[09:29:02] <meeting> *autotraductor Crazy
[09:31:11] <icarito> tch__, you think that 0.98 is shippable in jessie in it's current state?
[09:31:13] <icarito> jessie is in deep freeze
[09:31:23] <icarito> so it's not possible to add packages or update versions
[09:31:28] <icarito> I think it's too broken
[09:31:42] <icarito> we should not ship that with brand new stable debian
[09:31:52] <icarito> if we have a say
[09:31:57] <icarito> but it's ultimately up to jo0nas
[09:33:06] <icarito> i'm not saying we shouldn't have packages for jessie, just that we have zero chance of having quality packages in by release
[09:34:00] <icarito> we can strive to better support debian family by next release
[09:35:52] <tch__> icarito, can't comment as I haven't tested 98 specifically, I been testing 104 and it was looking good to me.. But, I am just in the process of getting familiarized with Debian packaging policies, I am sure jo0nas knows what hes doing
[09:36:14] <tch__> icarito, i just though I needed to clarify
[09:38:00] <icarito> tch__, maybe the missing piece of info was that jessie is slated for release 25th April
[09:38:04] <icarito> so it's in deep freeze
[09:38:29] <icarito> the question is more about what to keep from the old packages
[09:38:34] <icarito> because new ones can't get in
[09:42:37] <tch__> icarito, I understand, then there is nothing much I can add to the discussion really, as I haven't tested 98
[09:59:40] <santiago> lo mejor de colombia es que es tradición tomar chocolate al desayuno :-D -> indiscutible
[10:02:33] <santiago> y mejor si se acompaña con una arepa
[10:38:32] <GitHub155> [sugar-artwork] godiard pushed 2 new commits to master: http://git.io/vvstw
[10:38:32] <GitHub155> sugar-artwork/master e4b116f Sam Parkinson: Add compiled GTK3 theme source to .gitignore
[10:38:32] <GitHub155> sugar-artwork/master 27fac30 Sam Parkinson: Add a border for checkboxes
[10:39:02] <GitHub30> [sugar-artwork] godiard closed pull request #47: Add a border for checkboxes (master...checkbox-boarder) http://git.io/vvI1t
[11:44:55] <GitHub172> [sugar-artwork] godiard created checkbox_border_in_journal (+2 new commits): http://git.io/vvsD8
[11:44:55] <GitHub172> sugar-artwork/checkbox_border_in_journal 308cf30 Gonzalo Odiard: Show checkbox borders in the Journal
[11:44:55] <GitHub172> sugar-artwork/checkbox_border_in_journal dc1f43f Gonzalo Odiard: Show border in checkbox in toolbars and palettes...
[11:48:04] <GitHub80> [sugar-artwork] godiard deleted checkbox_border_in_journal at dc1f43f: http://git.io/vvsSs
[11:48:47] <GitHub169> [sugar-artwork] godiard opened pull request #48: Checkbox border in journal and palettes (master...checkbox_border_in_journal) http://git.io/vvsSX
[11:49:03] <jo0nas> tch__, icarito: thanks for your input - icarito points out the crucial detail that now is too late for *any* functional changes
[11:49:20] <tch__> jo0nas, ok, I understand :)
[11:49:29] <jo0nas> tch__: what you've tested is not Sugar _in_ Debian but Sugar _targeted_ Debian
[11:49:55] <tch__> jo0nas, yes, I understand now, apologies for the confusion
[11:50:08] <jo0nas> have a look here: https://qa.debian.org/developer.php?login=debian-olpc-devel@lists.alioth.debian.org
[11:51:30] <jo0nas> that gives an overlook of which suite (a.k.a. branch) of Debian has which version of package maintained by the Debian OLPC team (which now will change to the Debian Sugar team)
[11:51:44] <jo0nas> no need for apologies!
[11:52:06] <jo0nas> I really appreciate your input
[11:52:47] <jo0nas> if only you knew how lonely I've felt for years in my work packaging Sugar for Debian
[11:53:58] <jo0nas> that you may be inaccurate in your knowledge of Debian is no problem at all: your very interest - backed up by concrete testing and bug reporting and questioning things is great!
[11:54:17] <icarito> jo0nas, i'm sorry about that I've always cared but hadn't had a hope of deploying to users until now
[11:54:33] <jo0nas> no problem
[11:54:52] <jo0nas> you've done other exciting stuff no dpubt
[11:54:56] <jo0nas> doubt*
[11:55:42] <icarito> in the grand objective of bringing software freedom to education
[11:55:43] <jo0nas> I have felt very alone, but it is not aimed at anyone specific
[11:55:44] <icarito> :-)
[11:55:58] <jo0nas> and I have managed
[11:56:26] <icarito> jo0nas, it's a bit of a chicken and egg problem
[11:56:31] <icarito> we felt like that for years I guess
[11:56:42] <icarito> we even build an OS image without hope that they would use it
[11:56:44] <icarito> until they did
[11:56:53] <icarito> so its a bit like ghandi
[11:56:56] <icarito> first they ignore you
[11:56:59] <icarito> then they laugh at you
[11:57:06] <icarito> then they fight you
[11:57:07] <icarito> then you win
[11:57:08] <icarito> :-)
[11:57:23] <jo0nas> when I started working on Sugar, the Debian OLPC already existed with some 10 people subscribed - my feeling lonely stems from a too high expectation: I thought at least some of them would be active collaborators :-/
[11:57:41] <icarito> for me debian is a great model for sugar labs, because of it's organizational model and obvious success
[11:58:23] <jo0nas> right - the Sugar project itself has been quite a struggle for acceptance, I can imagine
[11:58:40] <icarito> jo0nas, our ranks have been greatly reduced, yes
[11:58:51] <jo0nas> I am talking about a far less of an issue - and a personal one - with my Debian packaging of it
[11:59:14] <icarito> jo0nas, yes it comes down to actual stuff we build in the end
[11:59:42] <jo0nas> Debian packaging have had the luxury of actual working code existing and tested in another platform (Redhat/Fedora)
[11:59:52] <jo0nas> so task is relatively simple
[12:00:16] <icarito> jo0nas, i'm still confused after all these years with the terminology even, sucrose for instance
[12:00:16] <jo0nas> ...even if still quite a large one - especially for one person
[12:00:26] <jo0nas> :-)
[12:00:41] <jo0nas> for the record: I have*not* been all alone - only mostly
[12:00:50] <icarito> we called our XO image HeXOkinase (it's an enzyme to digest sugar ;-)
[12:01:26] <jo0nas> Luke helped around 2008-2010
[12:01:48] <icarito> cool, he's MIA now from it seems
[12:01:51] <jo0nas> and around 2013 santiago_ helped
[12:02:15] <icarito> during these times there was efforts by quidam, did you get some input from that work?
[12:02:18] <jo0nas> Luke has moved on to other things, it seems
[12:02:36] <jo0nas> I have not reached out to parallel packaging efforts, no
[12:03:12] <icarito> for a long time we still recommend the Trisquel TOAST
[12:03:24] <jo0nas> ok
[12:03:39] <jo0nas> there are many ways to do things
[12:04:05] <jo0nas> as I said I have looked, really, but I expect other efforts to do things differently
[12:04:35] <jo0nas> e.g. using scripting, or short-from dh instead of cdbs, or...
[12:05:01] <jo0nas> on the outside the resulting packages may feel the same - either they work or they don't
[12:05:28] <jo0nas> but for maintenance there's different benefits in different packaging styles
[12:07:50] <tch__> jo0nas, think any of these changes (obviously not all) could be upstream material for Debian? https://github.com/tchx84/debian-abiword-packages/commits/master
[12:08:08] * jo0nas clones and looks...
[12:08:13] <tch__> jo0nas, these are the changes I made to make abiword python bindings to work and be packaged, to make Write activity to work
[12:13:37] <jo0nas> hmm - looks like essentially you add --enable-introspection to configure, disable a lot of stuff (which other packages in Debian may depend on), and add a new binary package for the produced introspection files
[12:14:52] <jo0nas> the package already had that --enable-introspection but commented out - and your commit indicates the reason might be it is incompatible with Debian multiarch
[12:16:13] <jo0nas> tch__: I suggest you file a bug against that source package (i.e. reportbug src:abiword ) of severity minor requesting they enable the introspection build
[12:17:52] <jo0nas> you can mention in that bugreport that you decided to use minor, not wishlist, because Sugar uses libabiword but newer releases require the introspection instead (i.e. it is not a completely new feature, but a change to existing independencies)
[12:18:47] <jo0nas> filing such bugreport might in itself get the ball rolinng - the maintainers might know what to do, just didn't know it was important for anyone
[12:18:57] <tch__> jo0nas, well basically the real novel things in there are (a) a bug in .install file for the gir package and (b) adding python-abiword to control (which otherwise is missing)
[12:19:08] <jo0nas> might also be they don't wanna work on it until after the release of Jessie
[12:19:17] <jo0nas> ok
[12:20:07] <jo0nas> right - so in *addition* to filing that bugreport, you can follow up in that bugreport with any helpful details you may have - like mention now!
[12:20:28] <jo0nas> it starts with a bugreport, to establish a dialogue with the maintainers :-)
[12:20:40] <tch__> jo0nas, ok
[12:20:43] <jo0nas> a bugreport in Debian is a mini mailinglist
[12:21:00] <tch__> jo0nas, one doubt, this is for a package that is in experimental
[12:21:04] <jo0nas> $bugnumber@bugs.debian.org
[12:21:11] <jo0nas> right
[12:21:13] <tch__> jo0nas, when does a experimental becomes ie., jessie?
[12:21:18] <jo0nas> never
[12:21:33] <jo0nas> experimental never becomes anything - it is a dead end
[12:21:40] <jo0nas> it is a playground
[12:21:48] <jo0nas> a fork of Sid, sort of
[12:21:55] <jo0nas> but...
[12:21:57] <tch__> jo0nas, ok, I get is not part of a pipeline or anything
[12:22:02] <jo0nas> right
[12:22:31] <jo0nas> so the learning gathered from experimental stuff needs to be reapplied to packaging done to Sid
[12:22:37] <jo0nas> s/to/targeted/
[12:22:42] <tch__> jo0nas, I will specify this works only for 3.0.1 which is not available yet for main Jessie
[12:22:53] <jo0nas> forget about Jessie
[12:22:57] <tch__> ok
[12:23:03] <jo0nas> you are not filing a bug about something broken
[12:23:16] <jo0nas> Jessie is at the current stage *only* about things broken
[12:23:30] <jo0nas> anything about new stuff is by nature not about Jessie
[12:24:02] <tch__> jo0nas, alright, won't mention it to avoid more confusions
[12:24:04] <jo0nas> 4 months ago it would be nice that you mentioned explicitly that you did not mean Jessie - but by now it should be obvious
[12:24:18] <jo0nas> you can - just saying you shouldn't need to
[12:24:27] <jo0nas> :-)
[12:24:44] <jo0nas> I don't think your last bugreport was confusing at all
[12:24:56] <jo0nas> don't expect your next one to be confusing either
[12:25:46] <jo0nas> when you file the bugreport, you can add the Debian Sugar team as "bug-cc" to have the team list subscribed to that bug
[12:28:01] <jo0nas> tch__: another detail, if you wanna improve: you made a git of all Debian packaging - both tarballs and uncompressed source material
[12:28:38] <jo0nas> more elegant is to track with VCS (i.e. git) only the unpacked material
[12:29:20] <jo0nas> if Debian maintainers already use git (and a git style that you can figure out how to use) then make a clone of that
[12:29:48] <jo0nas> else as starting point use only the unpacked directory - don't needlessly include the tarballs
[12:30:35] <jo0nas> a convenient way to clone maintainer VCS is with the command debcheckout
[12:31:21] <tch__> jo0nas, thanks, in this case was intentional to save some steps on different testing machine, but I reapply on top of maintainers fork to save them some headaches
[12:31:30] <jo0nas> "debcheck abiword" tries to clone VCS - and if a VCS is not found it instead does internally an "apt-get source abiword"
[12:31:42] <jo0nas> ok
[12:33:07] <icarito> jo0nas, tch__ what is your opinion on packaging activities vs .xo bundles?
[12:33:27] <jo0nas> 9I don't understand the question
[12:34:04] <jo0nas> oh, you mean Sugar fetching activities on its own, not using packaged code?
[12:34:14] <tch__> icarito, historically speaking, system packages were probably easier for large deployments who want automatic updates
[12:34:14] <jo0nas> that is problematic
[12:34:28] <tch__> icarito, but now sugar provides automatic activity updates
[12:34:32] <jo0nas> from a security POV it is problematic
[12:34:55] <icarito> .xo is not a good format for distributing binary code
[12:34:58] <jo0nas> Iceweasel browser downloading code for plugins on its own is a security loophole
[12:35:07] <icarito> also it has no provision for dependencies etc
[12:35:18] <jo0nas> well
[12:35:33] <tch__> icarito, yes, right about that
[12:35:35] <jo0nas> even if it was perfect regarding dependencies, it is still problematic
[12:35:50] <icarito> jo0nas, for example, do you think python's pip system works well for debian?
[12:35:53] <jo0nas> I am not judging as a competition between packaging systems
[12:36:16] <jo0nas> I have no opinion on whether RPM or DPKG is best - the both work!
[12:36:30] <jo0nas> .xo also, I assume, work for its purpose!
[12:37:04] <tch__> icarito, id say:
[12:37:06] <jo0nas> pip also, I assume, work for its purpose - as does Perl CPAN and all the other micro-packaging-systems
[12:37:44] <tch__> icarito, system package pro is dependency control and binary transferring (ie., delta rpms?), vs .xo is easier for mortals?
[12:38:30] <icarito> tch__, I don't have an answer really
[12:38:30] <tch__> .xo is just a zipfile and is independent of the system
[12:38:59] <icarito> jo0nas, tch__, alsroot had been working on a system to glue both using packagekit
[12:39:02] <jo0nas> it looks like .xo URL for updates is configurable: I consider for Debian packaging to change the default to something bogus - requiring a system administrator to change it if that system find it safe for its users to update out-of-band
[12:39:44] <jo0nas> having Sugar talk to pakcaing system of underlying system would certainly be good!
[12:39:58] <jo0nas> what I described was my intermediate hack
[12:40:48] <jo0nas> system package pro is testing and security vetting infrastructure!!!
[12:42:17] <icarito> here's the docs by alsroot http://wiki.sugarlabs.org/go/Platform_Team/Package_Management_System/1.0/Notes
[12:42:40] <jo0nas> you both use my debian.jones.dk packages on your testing systems - but none of you commented on its security warnings
[12:43:02] <icarito> jo0nas, perhaps we can motivate alsroot again ;-)
[12:43:07] <jo0nas> I could *easily* be running a keylogger on your machines by now
[12:43:13] <icarito> security warnings? you mean the lack of gpg signature?
[12:43:18] <jo0nas> right
[12:43:49] <icarito> jo0nas, i assume lack of gpg signature when I deal with unreleased packages
[12:43:50] <jo0nas> the verifiability of code
[12:44:00] <icarito> jo0nas, you could be running keyloggers even if you signed your packages
[12:44:06] <icarito> i didnt review them
[12:44:21] <icarito> only ran them
[12:44:28] <icarito> i mean in detail
[12:45:20] <jo0nas> my point is I could easily add a keylogger when _you_ fetched and not when others did so - i.e. *sneak* it in
[12:45:26] <icarito> the difference is that without gpg from you, somebody else could be running keyloggers if they intercepted my download
[12:45:36] <icarito> ah i see
[12:46:15] <jo0nas> right, others could too - if you used http instead of https (or if you used https and didn't check signatures for _that_)
[12:47:00] <jo0nas> that's a different issue
[12:47:09] <icarito> jo0nas, the same is true if you run any non-free software
[12:47:13] <icarito> even a driver
[12:47:33] <icarito> or a h264 codec ;-)
[12:47:38] <jo0nas> lot's of attack vectors exist, yes
[12:48:04] <jo0nas> my point is in not creating new ones
[12:48:47] <icarito> jo0nas, in any case it makes sense not to enable autoupdate
[12:49:15] <jo0nas> is there a correct way to disable it?
[12:50:28] * icarito looks it up
[12:51:35] * icarito not finding it, gonzalo_ or tch__ might know
[12:52:15] <icarito> the correct way to disable the autoupdater
[13:01:28] <icarito> tch__ has worked on the auto updater http://wiki.sugarlabs.org/go/Features/Optional_activity_updates
[13:03:36] <tch__> jo0nas, icarito back
[13:03:48] <tch__> jo0nas, you want to disable sugar's autoconnect?
[13:03:50] <tch__> sorry
[13:03:53] <tch__> autoupdaye
[13:03:55] <tch__> ?
[13:04:03] <jo0nas> right
[13:06:54] <tch__> jo0nas, 1secv
[13:06:57] <jo0nas> Optional_activity_updates seems different from what I seek
[13:08:02] <tch__> jo0nas, https://github.com/sugarlabs/sugar/blob/master/data/org.sugarlabs.gschema.xml#L288
[13:08:09] <tch__> jo0nas, there is a GSettings config
[13:08:15] <jo0nas> ideally I want updating to work but *only* updating activities already local to the user - i.e. installed by the user
[13:08:24] <tch__> jo0nas, you can provide an override file
[13:08:38] <tch__> to modify that setting
[13:09:23] <tch__> like those we use in olpc-os-builder
[13:09:25] <tch__> 1sec
[13:09:25] <jo0nas> that seems to be about updates happening in the background, not disabling user-initiated updated - no?
[13:09:44] <jo0nas> ...judging from its name
[13:09:57] <tch__> jo0nas, yes, is that what you want? or you want to get rid completely from sugar-level updates?
[13:10:12] <jo0nas> ideally I want updating to work but *only* updating activities already local to the user - i.e. installed by the user
[13:10:14] <icarito> tch__, maybe it can be a feature request, to "only update activities from ~/Activities" (aka installed by the user)
[13:10:38] <jo0nas> I imagine such distinction isn't implemented yet, right
[13:10:50] <tch__> jo0nas, that setting will disable automatic updates, but user will still be able to update from the Control panel section
[13:10:57] <jo0nas> so less advanced, I want to completely disable _all_ ability to update packages
[13:11:02] <jo0nas> right
[13:11:27] <jo0nas> I want the control panel to not work (as workaround for it working only on locally fetched activities)
[13:11:45] <jo0nas> I guess I can simply put a bogus URL for the update service?
[13:12:38] <tch__> jo0nas, yes, that could work too. Making sure there is no updating updates too.
[13:12:39] <jo0nas> i.e. make a custom "backend" that does nothing
[13:13:37] <tch__> jo0nas, could work also,
[13:14:32] <tch__> jo0nas, probably the most aggresive solution would be to completely remove the updates section and disable automatic updates, but really not sure you should go that far
[13:14:41] <tch__> jo0nas, I would not recommend that
[13:17:00] <tch__> jo0nas, probably the best choice is to do nothing, because the automatic updates are disabled by default and there is nothing to be done in cases where the users download .xo bundles
[13:17:18] <jo0nas> ?
[13:17:48] <jo0nas> my experience with status quo is that going to control panel updates system-installed activities!
[13:17:57] <tch__> jo0nas, I mean, even if we remove the updates section etc, they can still download .xo files from the internet and override whatever is in the system
[13:17:59] <jo0nas> that is bad from a Debian POV
[13:19:21] <jo0nas> there is a huge difference between activating the UI interface for "make my environment up-to-date" and "manually add new items to my environment"
[13:21:41] <tch__> jo0nas, in sugar you can download a .xo file and by clicking on it, it will install or update the activity
[13:22:04] <tch__> jo0nas, from the users POV is pretty neat
[13:22:10] <jo0nas> Have a look at this bugreport against Iceweasl for a related issue: http://bugs.debian.org/769716
[13:23:07] <jo0nas> In Debian, you can add plugins for Iceweasel either via DPKG or via bowser UI
[13:23:28] <jo0nas> the packaged plugin is *not* updated when you request updating plugins from the UI
[13:23:46] <jo0nas> only the UI-installed plugins are updated via UI updating!
[13:23:50] <jo0nas> that makes sense to me
[13:24:05] <jo0nas> makes sense to me that the user is not in prison
[13:24:24] <icarito> if a deployment wants to use sugar's autoupdate, it will put activities in ~/Activities
[13:24:37] <jo0nas> but makes sense to me that the user's house do not fall apart when the user tinkers with the door of the hous
[13:24:39] <icarito> not sure what OLPCOS does
[13:26:05] <jo0nas> seems to me that Sugar don't care where activities are located - updating (automated or manually triggered) installs updates in ~/Activities for *both* system-installed and ~/Activites installed activities!
[13:27:43] <jo0nas> ...which I believe ideally should be improved to distinguish (with configuration options for which things to then update), and until that is done I believe best workaround for Debian is to cripple the updating mechanism to not work at all (but yes, user can still install by browsing and installing that way)
[13:27:59] <jo0nas> makes sense?
[13:29:31] <icarito> jo0nas, it makes sense to me
[13:29:41] <jo0nas> ...the crippling can hopefully be done in a way so that the _sysadmin_ of the system (i.e. also the deployer of a batch of systems) can re-enable current upstream simplee updating mechanism
[13:29:45] <icarito> currently in production image for peru, we install activities in ~/Activities
[13:30:48] <jo0nas> please for next production image for Peru serve all its activities as Debian packages!
[13:31:29] <jo0nas> the deployer or the sysadmin should put *nothing* in $HOME!
[13:31:38] <tch__> jo0nas, considering that they can still update activities by browsing (which is probably more common than using the UI) I think is like swimming against the flow, but you as the packager and maintainer for Debian you should do what you have to
[13:33:58] <icarito> jo0nas, i "went with the flow", I think OLPCOS does the same
[13:34:02] <icarito> we went
[13:34:13] <icarito> because it was alsroot who built the "Deployment Platform"
[13:34:18] <icarito> as a reference upstream
[13:34:34] <icarito> we built Hexoquinasa from it
[13:34:52] <icarito> "Deployment Platform" was also called "Harmonic Distribution"
[13:36:13] <tch__> jo0nas, icarito: my point is, nothing we do to cripple the updating of activities via UI will change the fact that they can still update activities and they will do it, that is all :)
[13:39:42] <jo0nas> tch__: my point is that I do not want to lock down the system (so that the user is unable to install custom stuff) but to distinguish between system-provided and custom
[13:39:58] <jo0nas> there is today 1 (one) button to update activities
[13:40:31] <jo0nas> that button is in a control panel - i.e. in UI design experienced as the standard system
[13:40:48] <jo0nas> when you click the button for the standard system you expect the standard system to be updated
[13:41:08] <jo0nas> what really happens is you shift from standard system to partly custom-installed
[13:41:43] <jo0nas> ...where in my terminology here, "custom" means "located below $HOME"
[13:42:04] <jo0nas> ...and "system" means "located below /usr"
[13:44:20] <jo0nas> tch__, icarito: a related issue: instead of deployments throwing (i.e. without system-specific repackaging as RPM or DPKG) activities in ~/Activities, ideally Sugar should support throwing those below /usr/local/share/sugar/activities
[13:45:14] <jo0nas> might already work today - I haven't tried because I have little interest in throwing stuff - but if/when it works, deployers whould be strongly recommended to use that instead of messing in $HOME
[13:45:45] <jo0nas> it is fundamentally wrong of a sysadmin or deployer to mess in $HOME
[13:46:23] <tch__> jo0nas, I understand that, from my POV there is no difference between clicking on that button and downloading a .xo, because both are part of the UX design, and to be more direct I am not trying to persuade you to do or not do anything haha
[13:46:25] <tch__> :)
[13:46:32] <tch__> jo0nas, is something we should consider, I agree
[13:46:53] <icarito> jo0nas, i understand, but there would be a constructivist point to put Activities around $HOME umm as you see in the Home View in Sugar
[13:46:57] <jo0nas> don't worry, you probably cannot convince me to chance my standpoint here ;-)
[13:47:01] <icarito> i.e. they are meant to be messed with
[13:47:35] <icarito> but I agree with both of you
[13:47:41] <icarito> i.e. you are not really oppossed
[13:47:47] <jo0nas> icarito: heh - then why is gcc not in $HOME too?
[13:48:16] <icarito> tch__ with jonas's proposal (auto update only updates ~/Activities/* ) current behaviour should not be affected because images deploy in ~/Activities anyway, in my experience
[13:50:22] <jo0nas> with my proposal *no* behaviour need to change: Have the upstream configuration default be "paths-to-take-into-account-when-updating: /usr, /usr/local, $HOME"
[13:50:23] <tch__> jo0nas, icarito it could work, need to look in the code !
[13:50:44] <tch__> brb, forgot about lunch again
[13:51:00] <tch__> exciting discussions are bad for diet
[13:51:00] <jo0nas> then a _distributor_ can choose to change that default to only include $HOME
[13:51:21] <jo0nas> ...and the _deployer_ or _sysadmin_ could override the distro setting
[13:51:57] <jo0nas> ...and the user - no matter any of above - have *same* experience as today!
[13:52:45] <jo0nas> ...the *only* situation that would change the user experience would be if distro or deployer/sysadmin excluded $HOME from the setting - that would create a jail!
[13:53:30] <jo0nas> ...and such jail would be relevant e.g. for a kiosk or demo system (when what you want to demo is *not* constructionism on the lower levels of the environment)
[13:54:28] <tch__> jo0nas, would you be willing to share these ideas to our ML?
[13:54:37] <tch__> jo0nas, it could be a good place to discuss it
[13:54:53] <icarito> jo0nas, no such jail as you could always install from the browser I think
[13:55:09] <icarito> jo0nas, I think we should try to avoid bringing jails to the education system
[13:55:16] <icarito> bitfrost was a big loss of time
[13:56:24] <jo0nas> bitfrost tried to go beyond the UNIX design, within a UNIX framework which Linux is
[13:56:45] <jo0nas> I am *only* talking about using very core logic of UNIX design
[13:58:09] <jo0nas> a jail need more lockdown than update mechanism, yes.
[13:58:52] <jo0nas> but that's irrelevant for the point I am making
[13:59:01] * icarito must leave for now
[13:59:29] <jo0nas> I agree we should not lock down educational systems - but we should allow non-educational systems (i.e. kiosks) to also use Sugar
[13:59:41] <icarito> +1 on that
[13:59:57] <icarito> not primary goals are important too
[14:00:07] <icarito> multi purpose sugar :-)
[14:00:07] <jo0nas> a system setup locking down the user is violating a core principle of constructionism
[14:00:22] <jo0nas> which is why I mentioned that only as a bonus point
[14:04:05] <icarito> jo0nas, i think it is against constructivism to protect a used from himself i.e. not allow him to break things
[14:04:15] <icarito> *used/user
[14:04:32] * icarito must go buy a carrot to finish lunch
[14:04:42] <icarito> :-D
[14:05:27] <icarito> jo0nas, but we should work so the user is not subject to greater security risks than necessary and that the base OS is hard to break as well
[14:05:31] <icarito> talk to you later
[14:08:01] <jo0nas> it is not about ability to break things - it is about breaking only the things you are tinkering with
[14:08:11] <icarito> yup
[14:08:46] <icarito> if we come up with concrete proposals we have about a month window to add for 0.106
[14:08:47] <jo0nas> when you click "update" you do not expect it to mean "convert from Debian-governed to lesser-Debian-governed"
[14:09:10] <icarito> understood and agreed
[14:09:15] <jo0nas> today the upate button is implicitly a convert-most-possible button
[14:10:02] <jo0nas> I argue that it is deployment-specific if such conversion is beneficial or counterproductive
[14:10:30] <jo0nas> and I argue that such judgement has *nothing to do with constructionism or not
[14:11:31] <jo0nas> serving activities from asla or from Debian are both equally much external interference with your World as user
[14:24:50] <samsongoddy> tch_, ping
[14:45:15] <meeting> *gnome-*ssesion
[15:57:18] <abhinav> tch__, ping
[17:06:22] <GitHub199> [sugar-artwork] tchx84 pushed 2 new commits to master: http://git.io/vvnnG
[17:06:22] <GitHub199> sugar-artwork/master f87d4b0 Gonzalo Odiard: Show checkbox borders in the Journal
[17:06:22] <GitHub199> sugar-artwork/master e6f3c44 Gonzalo Odiard: Show border in checkbox in toolbars and palettes...
[17:06:32] <GitHub74> [sugar-artwork] tchx84 closed pull request #48: Checkbox border in journal and palettes (master...checkbox_border_in_journal) http://git.io/vvsSX
[18:49:58] <tch__> Quozl`, ping
[18:50:05] <Quozl`> tch__: hello!
[18:50:15] <tch__> Quozl`, hey!
[18:50:35] <tch__> Quozl`, did you have the chance to test abiword packages I sent?
[18:51:18] <Quozl`> tch__: not yet, but is on my queue for today. i'm looking at fedora 20 desktop stability for .uy right at the moment, #12872.
[18:52:02] <Quozl`> tch__: look at apt-ftparchive for a method to make packages file for a private repository, so that a trivial archive can be made from your /debian/ directory and added to sources.list ;-)
[18:52:25] <tch__> Quozl`, ok, will do
[20:42:39] <quidam> tch__: fixed collaboration in trisquel, thanks for the research on telepathy
[20:45:04] <tch__> quidam, np, the real research is only beginning though, so we can eventually fixed in it sugar without depending on old packages :)
[20:46:20] <quidam> tch__: that would be much nicer than my ugly hack, but it will do in the meantime
[20:46:50] <tch__> quidam, yeah, thanks for including the workaround in TOAST :)
[21:51:57] <Quozl`> tch__: ping. need dsc.
[22:00:33] <tch__> Quozl`, pong (about to leave though), how can I help?
[22:00:59] <Quozl`> tch__: do you have the other files you used in package build; .dsc, changes
[22:02:14] <Quozl`> if not, i'll dig into your repository and see if i can rebuild.
[22:02:22] <tch__> Quozl`, nope, its all here https://github.com/tchx84/debian-abiword-packages, but I will clean that up tomorrow to try to get it upstream
[22:02:37] <Quozl`> ok
[22:02:49] <tch__> Quozl`, it should be rebuild with the instructions I sent,
[22:02:53] <tch__> Quozl`, does not?
[22:03:28] <Quozl`> i'm trying to fit things into pbuilder, which triggers from a .dsc file. your .dsc file in that repo is perhaps what i need.
[22:05:15] <tch__> Quozl`, I did not touch that file, but it probably needs modification because I added 2 packages in the building
[22:05:37] <tch__> Quozl`, (not entirely sure how pbuild uses that file)
[22:05:56] <Quozl`> tch__: the .dsc contains references to all the other files used in building.
[22:08:44] <tch__> Quozl`, oh, then it needs modification, feel free to modify it if you have the time, Ill do the cleanup tomorrow early anyways
[22:08:56] <Quozl`> ok.
[22:09:18] <tch__> Quozl`, gtg, talk to you tomorrow!
[22:09:22] <Quozl`> bye
[03:00:43] [disconnected at Tue Apr 14 03:00:43 2015]