From a812cb16f3807c93e7da7aadb66bd3c1ac63759d Mon Sep 17 00:00:00 2001 From: Clement Lefebvre Date: Mon, 27 May 2013 20:03:05 +0100 Subject: [PATCH] Added meeting --- README.md | 3 +- meetings/2013.05.27/minutes | 296 ++++++++++++++++++++++++++++++++++++ 2 files changed, 298 insertions(+), 1 deletion(-) create mode 100644 meetings/2013.05.27/minutes diff --git a/README.md b/README.md index ca70b06..88f41fa 100644 --- a/README.md +++ b/README.md @@ -5,7 +5,6 @@ Bugs found in Mint 15 RC 2 System --------- - - Install smplayer2 for DVD playback? - No EFI El-Torito entry in the ISO. Verified with "dumpet -i file.iso". Ubuntu can boot on UEFI. Mint only has 0×00, so it only boots on BIOS(or CSM for UEFI) but not UEFI. @@ -14,6 +13,8 @@ Bugs found in Mint 15 RC - w32codecs, w64codecs, libdvdcss2 (previously hosted by medibuntu) are not in the repositories. + - Now I need to explicitly state “apt-get install skype:i386″ if I want to upgrade to skype 4.2 from the Mint repo, or either apt-get won’t know it can be updated. Since this is not the same package, apt-get will also want to remove skype and skype-bin:i386. + ======================================================================= Upcoming diff --git a/meetings/2013.05.27/minutes b/meetings/2013.05.27/minutes new file mode 100644 index 0000000..c04b143 --- /dev/null +++ b/meetings/2013.05.27/minutes @@ -0,0 +1,296 @@ +Topics: + +- General questions + +Actions: + +- @clem: add dependencies to Mint packaging for cinnamon in 1.8.x +- @clem: update nemo's translations in 1.8.x +- @clem: check all pull requests and finalize 1.8.x before 1.9 starts on the 1st June. + +Logs: + + Welcome everyone to this week's meeting +* autarkper (pang@SpotChat-hdol0m.cust.tele2.se) a rejoint #linuxmint-dev + there are no defined topics for this week + hi + hi + there's a couple of things I'd like to talk about though... + 1. l10n quality checking + 2. package dependencies in cinnamon + 3. start of 1.9 development + I'll tackle them in reverse order ... :) + #3... as promised, we'll start developing 1.9 on the master branch on the 1st of June + this week-end basically + so if you're already bored and waiting for this to happen, it's only a matter of days :) + #2, regarding dependencies... the biggest issue imo is the fact that cinnamon doesn't depend on cinnamon-common + and that some muffin packages necessary for cinnamon to work aren't in the deps either + I think that's something we should fix in 1.8.x +* AlbertP (albert@SpotChat-aofquv.solcon.nl) a rejoint #linuxmint-dev + #1, regarding l10n... we have bad translations in Nemo (in Turkish) and that makes Nemo segfaults when Turkish users copy files... + ideally we would test the quality of po or mo files within our packaging and the packages would not build if a problem was found + that's something we can address in 2.0, and in the meantime Nemo should get newer translations in 1.8.x + I'm putting two actions on myself: + - adding dependencies to Mint packaging for cinnamon in 1.8.x + - updating nemo's translations in 1.8.x + that's it from me :) + any comments? questions? + clem: are you talking about make some sort of parse tool to check translation files? + mtwebster: yes, either that or using a gettext tool (if there's one that's suitable) + mtwebster: the main thing would be for arguments to match + ie decompile .mo then check result file for validity + mtwebster: for instance yes + can't you simply grep that? + d[-_-]b: msgunfmt produces the po output afaik + I'd also like to simplify how we package translations... + it's a real pita to update each package like that + in Mint none of the tools ship with their translations, they all use mint-translations + in Cinnamon, we've got translations in nemo, in cinnamon, etc etc... and the more tools we support the more work that's going to be + clem: well you could use a tool that allows translators to push translations into version control directly + d[-_-]b: you'd still need to bump the versions and package it up + d[-_-]b: you'd lose the ability to freeze content too + that's a question we don't need to ask ourselves right now... but within the 2.0 cycle, we should consider whether it makes sense to simplify l10n + then how do other projects handle it? + the way we do now + it's tedious though + when I upgrade translations, I basically take them from LP and update nemo, cinnamon, mdm, mint-translations +* DarkEra est parti (Quit: Leaving) + and that's ok... but tomorrow if I need to do it for each cinnamon component (ccc, csd, screensaver, etc etc..), I don't know... + at some stage I don't really care about people running nemo 1.6 with cinnamon 1.8 or running nemo without cinnamon + at some stage it might make more sense to simply have cinnamon translations, and all cinnamon components use the cinnamon gettext domain + so if you could just upgrade the version control with a single click that would make things easier? i'm not sure bout putting everything together + I'm sorry but I need to help somebody else with a computer problem. I have to go now. + the only gain we get from having it the way it is now, is that all components include their own translations... and are thus usable individually + that's not something we should really care about though, since they were developed for the sole reason to make cinnamon better +* AlbertP est parti (Quit: Ik ga weg) + i personally would prefer to keep it that way. i would find it weird if someone decided to use nemo on unity and can't because translations are missing +* Oscar799 est parti (Quit: Leaving) + d[-_-]b: they could + d[-_-]b, translations wouldn't be misssing + d[-_-]b: but it would show up in English + d[-_-]b: or they'd have to install cinnamon as well (which is already the case I think) + now who of you is right? + d[-_-]b, they would have to install cinnamon-translations (or something like that) + glebihan: i see. seems not right to me in a way + d[-_-]b: why not? + d[-_-]b, as clem mentioned, we're developing as a part of cinnamon, if some people want to use it outside of cinnamon, that's their choice + developing *nemo* + because you will have to install things you don't really need + if it's only a translations packages, I don't see what the problem is + glebihan: i know. but thinking what might happen sometime in the future. let's say people decide to fork certain stuff + d[-_-]b, let them deal with that then + d[-_-]b: indeed, but we've never portrayed any of the cinnamon components as independent software developed for the Linux community + fwiw, i agree... seems to make more sense to do the translations once, rather than for each and every component + d[-_-]b: in a way we let cinnamon be portrayed like that, but not nemo, not the cinnamon-screensaver (which even wears the name) + so if tomorrow I hear some unity users replaced gnome-screensaver with cinnamon-screensaver, that's great.. but they're on their own + because I won't have them in mind in my design + that's not a responsibility we ever accepted + like glebihan said, they just download/install cinnamon-translations as well, and they should be fine in that regard + note also that this is mostly a packaging thing + clem: but it's only to make life easier right? if there was a chance to develop everything with its own translation at the same amount of work you would do that? + Mint might use cinnamon-translations while fedora say, might continue to ship translations as part of nemo/cinnamon-common/ etc... + d[-_-]b: I wouldn't break things for people without reasons, whether it's within our outside my audience + clem: ok so the translations will still come seperated (lets say seperated po's) + d[-_-]b: updating translations at the moment is ok... I don't do it very often because it's a bit of a pain... but if we continue to develop more tools, at some stage I'll want to factorize + and no possibility to put them all to packages automatically? + d[-_-]b: from a pure pragmatic point of view too... a translation package is an all package... it doesn't need compiling. + d[-_-]b: so it's much easier to maintain + d[-_-]b: right now for instance I'd much prefer to update cinnamon-translations than to release a new nemo + d[-_-]b: from LP to github directly? + eg + d[-_-]b: it can be done from LP to bazaar I think, but I'm not really interested in that + clem: eg pootle can do that + d[-_-]b: I can also automate it on my end, but it's more a problem of maintaining multiple translations than the fact that it's manual + d[-_-]b: having new translations should translate as having new translations... not a new nemo, a new screensaver, a new cinnamon etc.. + anyway, food for thought, let's talk about this later when we get into 2.0 + i totally agree with that. i thought it was if there are nemo-translation and screensaver-translation or just cinnamon-translation + any other questions/topics/remarks/comments? + just a quick note: the missing translations for synaptic are done already. but they don't get reviewed for whatever reason + d[-_-]b: in what language? + german + d[-_-]b: wait, synaptic.. we don't maintain these + d[-_-]b: that's part of either synaptic or language-packs + i know. just because i recognised they were missing (that's why i asked mtwebster earlier) + ok + clem: last week I think you said you were going to have a look at https://github.com/linuxmint/Cinnamon/pull/2048, or am I mistaken? + autarkper: you're right :) + autarkper: I'll add an action on myself for this + clem: I'm not insisting personally + autarkper: hehe :) + autarkper: I'll have a look and probably push it to 1.8.x + there are a number of others that are probably good for 1.8 + clem: sounds good + I'll have a look + I'm not as much in a hurry to get them in as before, as you probably know Mint 15 is on its way + the ISOs were approved and are syncing with mirrors as we speak + so the ETA for these is this week-end, since we start 1.9 on the 1st + did cinnamon-translations make it in? + d[-_-]b: no, that's 2.0 +* acewin est parti (Ping timeout: 121 seconds) + d[-_-]b: it's the first time we dicussed it + discussed + discussed what? + d[-_-]b: factorizing translations + clem, you say the ISOs are syncing ? I don't see them on heanet ? + clem: sorry i don't get it. so the translations eg for cinnamon-settings do not get in because there is no factorization yet? + glebihan: they start at pub.linuxmint.com then go onto heanet + clem, ok + d[-_-]b: no, each package contains its own translations right now + clem: yes. i'm only asking if the translations that were missing for cinnamon got into the new iso's^^ + (not talking about any cinnamon-translations package) +* acewin (acewin@SpotChat-0te.ap6.217.98.IP) a rejoint #linuxmint-dev + d[-_-]b: oh, no + d[-_-]b: even the turkish segfault came too late + d[-_-]b: they'll be available as updates though + ok + I don't know if you've all followed the feedback on Mint 15 RC, but it's been really impressive + I've never seen so much positive vibes personally + it should be easy to make sure tokens match up. I would think launchpad would complain if quotes mismatch + but i don't know for sure + there's a python lib - polib, that lets you parse through po and mo files, i'm messing with it now + some people had no sound, others had no bumblebee, couldn't join hidden essid networks and so on... we had bad critical issues... + yet people didn't mind too much + because it's sexy + 1.8 brought its fair share of new features, but I think the big thing here is that it's more tightly integrated than before + it's not just a shell anymore + nemo isn't just better now, it looks better + and there's screensaver, control center modules, desklets... you really feel like you're running a DE + even though you aren't... yet + mtwebster: in the case of nemo's TR po, I think it was because of quotes.. + mtwebster: afaik the arguments matched and to me even the quotes looked fine + clem: the args are reversed + mtwebster: let me find the string.. + the quotes are fine + 38651:msgid "Moving file %'d of %'d (in \"%B\") to \"%B\"" + 38704-msgstr "Dosya(\"%B\") 'den \"%B\" 'ye ta..n.yor %'d / %'d" + msgid "Moving file %'d of %'d (in \"%B\") to \"%B\"" + msgstr "Dosya(\"%B\") 'den \"%B\" 'ye taşınıyor %'d / %'d" + hehe :) + %B is a custom token, of a string + mtwebster: why is it done with %s and so on? i know in libreoffice they do it like ($HEIGHT)x($WIDTH). so you can push args around as you like + I don't understand why it fails + clem: because it's putting an integer where it expects a string + and vise versa + mtwebster: why? + because our l10n strings aren't good + the argument list is unchanged (, int, int, string, string) + but our tokens in the translated string are string, string, int, int + we should specify the argument index in the string + ie %1$s instead of %s + well we can name them right? + look at my post? + in python you can %(somename)s + not sure + clem, should be possible, I've never used that, i always use indexes +* chattr est parti (Connection closed) +* chattr (regnad_kcin@old.same.place) a rejoint #linuxmint-dev + d[-_-]b, that's messy + glebihan: well it avoids the problem. + _("%(mystring)s blah %(myint)d" % {mystring: myval; myint: 2}) + we use dicts in python for that + d[-_-]b, it's also much more trouble code-wise, when there are native solutions to workround it +* shantorn (Shantorn@SpotChat-6jgom3.cust.wildblue.net) a rejoint #linuxmint-dev + glebihan: i don't think they invented it on their own like that on libreoffice.. + actually, my example is broken :)) + but heh, we use dicts anyway :) + d[-_-]b, maybe they did, maybe they didn't, it's still messy + d[-_-]b, that would mean we stop using gettext functions and rely on some replace function + regardless how we solve it, we have to make sure translators understand, and have a way to check mo files + mtwebster: so you're saying any language where the arguments aren't in the same order is going to produce segfaults if they're of different types? + the check utility is simple to do, explaining to translators i dunno + clem: yes, it doesn't know any different + omg... + you're giving it an int where it expects a string + it makes perfect sense to me :) + you should have been born a computer mtwebster + lol + clem, but that's because using several arguments in an l10n string without indexes is bad practise + segfaulting in the user's face is considered bad manner too :) + and even if you add indices noone will ever know what will be inserted (you can only guess) + right, we need to fix that in 2.0 :) + we can't go on using unnamed/unindexed args in the same l10n string :) + clem, right, but even if the arguments were of the same type, it would still be an issue. There wouldn't be segfaults, but words in the wrong order + glebihan: yes, that much more ok though + clem, agreed + progress: 100 out of 34 files were copied so far.. + in the mint tools there are occurences like that... + some are named others aren't + python doesn't care about types as much though + so it's more a problem for translators than for us + yeah python just tries to make sense of it +* autarkper est parti (Ping timeout: 121 seconds) + ok let's tackle these in 2.0, for now I'll update the translations for nemo + d[-_-]b, they will know just as well as they do now + the Turkish translators basically turned their sentence around to match our argument order... + glebihan: yes. that's part of the problem + it probably sounds weird in Turkish now, but at least they'll get to read something :) +* kaie (kaie@SpotChat-sot7hh.dip0.t-ipconnect.de) a rejoint #linuxmint-dev + d[-_-]b, well, translating always requires to know where the strings are being used, you can't just blindly translate without seeing the applicaiton + until another translator "fixes" it and it segfaults again :) + d[-_-]b, I don't see that as a problem, it's just how it is + glebihan: it's still slower than if you knew what the arguments mean directly + mtwebster: you want to talk about csd? + clem: sure + d[-_-]b, not really, because you often can't know what a sentence means outside of its context (whether there are arguments or not) + i've got it operational in mint 15, and it compiles in lmde. I have branches for nemo, cinnamon, cinnamon-control-center that implement changes to use c-s-d instead of g-s-d + i'm going to start work on porting media keys into cinnamon + same with people, to be taken within their context... some guys around here don't make any sense outside of the pub for instance, we tried to talk a few times, and we always ended up agreeing we'd meet in the pub instead... + lol + mtwebster: so, one we use csd... other than gnome-session, are we still using any part of GNOME? + clem: gnome-desktop is used a great deal - that's mostly libraries though + i don't think we need to fork at this point + mtwebster: these are utility libs, if they don't change often there's no need to fork them + mtwebster: I don't know if they do though + if we look at the issues we had with arch/fedora, we're mostly talking GSD... and then after there's regressions in what? gjs? cogl, clutter? + i haven't been able to get c-s-d actually start with the session in lmde - i don't know enough about debian though, it seems /etc/xdg/autostart isn't used + clutter, gjs so far i think + mtwebster: no, it shouldn't use it + mtwebster: the session starts components according to their session tags (in their desktop file) + mtwebster: I'm definitely having a look at gnome-session to see if we're better off having our own session though... + well - it's behaving differently than ubuntu, regardless + mtwebster: not necessarily a fork of gnome-session.. it could be a simple binary or even a script to start the cinnamon session + for now, I'm having cinnamon call itself "X-Cinnamon" in the session startup, that prevents gnome-s-d from starting + then in main.c of cinnamon, I re-set XDG_CURRENT_DESKTOP back to GNOME so we get our applications back + mtwebster: that's got "ditch gnome-session" written all over it + the only regression i've seen is the gnome-keyring stuff + i.e. it's asking me to unlock it when i fire up chromium + but that's probably something simple + and to do with my session name not being GNOME + anyhow, i wanted to get a head start on this for 2.0. and so far it's been a good decision to fork it, imo + oh yes, I don't think there's a choice here + it'll eliminate a lot of fixes currently in that gnome-3.8 rollup also + eliminate the need for i mean + it's the weakest point in Cinnamon at the moment, it makes no sense to use the GNOME backend + long term it means we're going to have to maintain these configuration tools of course + i've got a cinnamon-settings-daemon branch in my nemo, cinnamon, and cinnamon-control-center repos on github + so that's more work for us, but we can all agree on the fact that some of them suck, so that's an opportunity to improve things as well + yes + I wouldn't mind downgrading some actually... the printers module for instance + or porting the simple ones to python + anyway, we've got 6 months for all that :) + i planned on porting media-keys and the OSD popups to cinnamon + well, we need to talk about the panel + whether we want one or not + and what that means to things like OSD and all + what panel? + a gtk panel that works when cinnamon crashes + at the moment it's called gnome-panel + oh yeah + CSD would run everywhere whereas cinnamon would only work on some specs + so there's pros and cons to porting things to cinnamon +* kaie est parti (Quit: Leaving) + how critical is osd if you're in emergency mode though? + also, people might want to use CSD with unity + :)) + I'm kidding... :)) I heard the same joke about nemo though + *not laughing at all :P* + well that's perfectly valid :) +* o0ze (ooze@lookup.failed) a rejoint #linuxmint-dev +* o0ze est parti (Connection closed) + mtwebster: without OSD you cant' see the name of the song you're playing.. I'd say that's pretty CRITICAL! :) + yes, because : oh my desktop just crashed, I'm in some kind of fallback mode, let me listen to some music while I fix that (and don't you dare telling me I won't see which song is playing) + mtwebster: I don't know about you but I'd rather use OSD than Shazam when my computer plays a song I like... +* d[-_-]b est parti (Quit: Leaving.) + anyway, I guess we can discuss this outside the meeting :)) + lol + thanks everybody for being here, see you all at the next meeting ;)