Re: GitLab postmortem
On 15/01/2019 10:48, Bastien Nocera wrote: > On Tue, 2018-12-11 at 14:22 +0100, Carlos Soriano wrote: >> Hey, >> >> It has been a few months since we moved to GitLab. Apart of spurious >> issues, specific annoyances and frustrations, seems it has been >> generally good. I would like to gather some general feeling about it. >> Things that really made a constant impact to you and your work, both >> bad or good. Feel free to provide feedback about the transition or >> the administration of GitLab instance too. Free form. >> >> Please keep the mail chain one way from you towards the world, so we >> don't get trapped on specifics, we can address stuff raised here >> individually out of list. Personally, I'll ping you on IRC or so if I >> can do something to help. >> >> Of course, feel free to msg me directly on IRC/email too. > > My main problem is/was that contributing by pushing a branch is super- > easy, but you can't contribute by pushing a branch if you're not > allowed to push a branch. So this isn't a problem when you're in > @GNOME, and the project is as well, but I've not bothered pushing small > fixes to non-GNOME group modules. It should still be easy to fork the project, push a branch to your namespace, and then submit a MR. Or did I misunderstand? Emilio ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: [GitLab] Projects moved, tips of the week and question of the week
On 26/01/18 16:51, Jeremy Bicha wrote: > On Fri, Jan 26, 2018 at 6:22 AM, Timm Bäder wrote: >> https://gitlab.gnome.org/help says 10.4.0 > > Does anyone know why the version number doesn't show up on > https://salsa.debian.org/help (I believe it's using GitLab CE 10.4.0)? Probably a Debian customization, looks like the remove the header. Ask on #alioth on OFTC. And yes, it's using 10.4 (I asked recently). > If you wanted an account at Salsa, you can use > https://signup.salsa.debian.org/ Who wants that? I think I got lost but I don't see the connection. Cheers, Emilio ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Librsvg 2.40.20 is released and is the last release in the 2.40.x series
On 18/12/17 18:11, Federico Mena Quintero wrote: > On Sat, 2017-12-16 at 14:48 +0100, Michael Biebl wrote: > > [dropping distributor-list from the thread] > >> We'd love to switch in Debian, but >> >> https://buildd.debian.org/status/package.php?p=rustc&suite=unstable >> >> is effectively preventing us from doing that. >> Looks like Firefox 57 is not coming to stable Debian release either >> anytime soon: >> https://buildd.debian.org/status/package.php?p=firefox&suite=sid > > This sort of thing, where Debian has trouble compiling $new_thing on > $some_arch, comes up periodically. > > The only concrete suggestion I have for Debian is, feel free to patch > packages that depend on librsvg to keep using 2.40.20. That's an option, but instead I've been pushing to get the rustc ports for official Debian architectures fixed for some time already, anticipating that this would eventually be a problem (as is the case now). Hopefully we can get (some of) them ready soon (fsvo soon), and then update librsvg to 2.42. Cheers, Emilio ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GitLab update: Moving to the next step
On 07/12/17 21:04, Michael Catanzaro wrote:
> I use a long canned reply to close probably half the bugs I receive ("here is
> how you report a WebKit bug..."), and bug management would be extremely
> frustrating without it. I could keep it in a text file and copy/paste for a
> couple months, as long as upstream has promised the feature is on the way.
> But I
> really would rather stay on Bugzilla forever rather than give up canned
> replies
> forever. I am going to be thinking "I hate GitLab" every other time I close a
> bug... we don't want that.
Can't you write a simple greasemonkey script to add canned replies to gitlab,
until they are implemented upstream?
Cheers,
Emilio
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Relicensing Nautilus to GPLv3+
On 18/05/17 18:22, Carlos Soriano via desktop-devel-list wrote: > Hello, > > After asking some authors of the current code that we have as GPL3+ inside > nautilus, and pondering for a while, I realized the practicity of moving away > from that code or convince those authors to relicense as GPL2+ is more a > burden > than the real benefit. > > The only problem that arises if Nautilus becomes GPL3+ as per yesteday > discussion in IRC at #gnome-hackers is that extensions that are GPL2-only > cannot > be used anymore. > Keep in mind GPL2+ are fine. > > Said this, I took a look at extensions which are not retired from distros and > that have seen a release in at least the last 3 years. So far they are: > nautilus-dropbox - GPL3+ > nautilus-image-converter - GPL2+ > nautilus-pastebin - GPL2+ > nautilus-python - GPL2+ > nautilus-search-tool - GPL2+ > nautilus-sendto - GPL2+ > nautilus-terminal - GPL2+ > > Which is completely fine. As someone already mentioned, if any of those extensions links to a non-GPL3-compatible library, then they won't be compatible with a GPL3+ nautilus. In other words, extensions are now forbidden from linking to GPL2-but-not-GPL3-compatible libraries. I don't know whether there are any examples of extensions that do this. Just thought I'd point this out so the final decision is an informed one. Cheers, Emilio ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Tracker as a security risks
On 05/12/16 14:03, Hanno Böck wrote: > Hi, > > I wanted to point out a recent blogpost by IT security export Chris > Evans: > https://scarybeastsecurity.blogspot.dk/2016/11/0day-poc-risky-design-decisions-in.html > > The short version: Chrome automatically downloads files without a file > dialog, tracker (part of the GNOME desktop) subsequently automatically > indexes these files with a wide variety of parsers (including > gstreamer, but also others like imagemagick). > > While the bugs that evans points out have been fixed (and the gstreamer > team has fixed a whole bunch of other potential security issues I > reported in the past days, thanks!), the whole design of Tracker seems > incredibly risky. It is certainly worthwhile trying to make the > underlying software more secure, but having tried to do that before > I find it unlikely that projects like gstreamer or imagemagick will > ever be in a state where we can feel comfortable feeding them with > untrusted files. > > The core problem here is that tracker automatically parses files of > potentially unknown origin with parsers that haven't been built with > security in mind. This happens without any sandboxing. > > I think there needs to be a wider discussion about this and the > fundamental design choices done here need to be questioned. Thanks for starting this discussion. I think these questions also apply to the thumbnailer service and to gtk+/gdk-pixbuf APIs, e.g. the filechooser. See e.g. http://www.openwall.com/lists/oss-security/2016/07/13/11 aka CVE-2016-6352, and http://seclists.org/oss-sec/2016/q3/7 aka CVE-2016-6163. Cheers, Emilio ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: notes on building 3.20
On 23/03/16 18:00, Bastien Nocera wrote: > On Wed, 2016-03-23 at 12:44 -0400, Matthias Clasen wrote: >> Hey, some quick observations from building the 3.20.0 moduleset with >> gcc 6 on Fedora 24: >> >> gcc got a lot better. That means it has a lot more warnings. The ones >> that affect multiple modules are -Werror=format-nonliteral and >> -Werror=format-y2k. Both of cause build failures all over the place. >> >> Please make an effort to fix these in your code. At least the >> format-nonliteral warning often indicates actual, exploitable >> security >> holes. > > If you still have gcc 5, you can make this error show up by using those > CFLAGS: > -Werror=format=2 -Wformat=2 > > Make sure that -Wformat=2 isn't overwritten later in the CFLAGS list. > And for those on Fedora 23, you can easily install GCC 6 to enjoy the > build breakage yourselves by running: > dnf update --releasever=24 gcc binutils In Debian, gcc-6 is available from experimental. Emilio ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Power switch to actually turn off my computer
On 10/04/14 13:50, Charles T. Smith wrote: > Florian Müllner gnome.org> writes: > >> >> On Thu, Apr 10, 2014 at 1:01 PM, Charles T. Smith >> gmail.com> wrote: >>> The problem is, I'm new to this group (but I like it!) and I don't know >>> where to find org.gnome.settings-daemon.plugins.power - I mean, somewhere >>> where I can grep it. >> >> I used git-grep in the gnome-tweak-tool source tree, but a simple >> >> grep -R 'Power Button Action' /usr/lib/python2.7/site-packages/gtweak >> >> should work as well. >> > > > Okay, now I understand. tweak_group_shell.py configures that object-id, > org.gnome.settings-daemon.plugins.power, so gnome can manipulate it. In > this case, grep is no longer my friend. If tweak-tool sets org.gnome.settings-daemon.plugins.power, then something listens for that key to change and does something. You need to look for that something. And that something is going to be gnome-settings-daemon, and more precisely, its power plugin. Now go read the source, Luke! Emilio ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Zenity missing releases?
Hi, On 10/12/13 16:45, Arx Cruz wrote: > Hi, > > I'm the atual maintainer, it's true, I don't have upload access and I don't > have knowledge to create the package and upload,. If someone help me with > that, I would appreciate and assure that you guys will have the latest > versions of zenity :) To generate the tarballs you call make distcheck. To upload them you need an account. Have a look at https://wiki.gnome.org/MaintainersCorner/Releasing, it has a checklist and some useful information. Emilio ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: launch gnome-panel when gnome-session starts
On 14/10/13 13:19, Giovanni Campagna wrote: > 2013/10/14 Marc des Garets : >> Hi, >> >> I don't find how to launch gnome-panel when gnome starts. I have tried to >> add an entry in gnome-session-properties without success. >> >> So far I run: gnome-panel --replace after gnome has started. > > You can't run gnome-panel togheter with gnome-shell (they both claim > the org.gnome.Panel dbus name), so you'd need to define a different > .session file in /usr/share/gnome-session, referencing > gnome-panel.desktop instead of gnome-shell.desktop (as well as some > WM, for example mutter.desktop) > > But this seems a little out of scope for this mailing list, which is > for development discussions of GNOME. You should look at a different > forum for user help. E.g. https://mail.gnome.org/mailman/listinfo/gnome-flashback-list Cheers, Emilio ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Blocker bug review ahead of freeze
On 16/08/13 16:39, Dominique Leuenberger a.k.a. Dimstar wrote: > > Quoting Matthias Clasen : > >> Hey, >> >> the 3.9.90 release is coming up next week - it marks the beginning of >> our freezes, so this is a good time to review the blocker bug list >> again. After my first post earlier this week, I got some >> contributions, so the list is well-populated now. >> NetworkManager >> >> >> 701078 Port NM to BlueZ 5 > > IMHO, this is very late to happen 'just before RC' (3.9.90 is on Aug 20) with > a > full ABI/API freeze. > > As of now, distros did not do the switch to BlueZ5 as > * It can not be parallel installed with BlueZ4 > * It is not backwards compatible > * So far, only very few components know how to use it > > Of course, at one point we will have to bite the bullet... but 'just before > RC' > for such a drastic change is, in my opinion, not the best way; > > And I don't think NM is even the only piece in the GNOME stack affected; from > a > quick glance, I can see at least also: > * GVFS (backend; can probably be disabled). > * gnokii (seems those Nokia phones just don't die!) > * gnome-phone-manager (mostly obsolete I guess). > > And stuff outside of the reach of GNOME: > * PulseAudio (has a bluetooth module) > * qemu (bring BT support to VMs) > > This all would be no issue if the variants could co-exist of course :( The NM patches add a configure switch for bluez 5. If you don't pass it, bluez 4 support is compiled. As for the other modules, if you want 3.10 with bluez 4: gnome-shell: you need to revert a trivial patch gnome-control-center: likewise gnome-user-share: stay at 3.8. the only changes after 3.8.3 are bluez 5 support so you won't miss anything. gnome-bluetooth: stay at 3.8. 3.9/3.10 drop support for bluez 4 and change the libgnome-bluetooth ABI. NM: don't pass --enable-bluez5. Cheers, Emilio ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: BlueZ 5
Hi, On 16/08/13 17:51, Kalev Lember wrote: > not getting ported for 3.10: >gnome-user-share This got ported, although there are a couple of glitches, see https://bugzilla.gnome.org/show_bug.cgi?id=694347 Cheers, Emilio ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: New GnomeGoal proposal: InstalledTests
Hi, On 04/26/2013 05:01 PM, Colin Walters wrote: > On Fri, 2013-04-26 at 10:32 -0400, Dan Winship wrote: >> I want "make distcheck" to still run all of my tests, to guarantee that >> everything works correctly when built from a tarball, not just when >> built from git. > > That's going to be a high bar to jump; but I suppose it makes sense to > have both during the transition and give downstreams time to teach their > build systems about revision control. I'm not sure I follow here. Are you implying that you want to stop making tarballs eventually? Cheers, Emilio ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
gir versioning
Hi, I'm running G3.6, and have updated gnome-desktop to 3.7.90 to test it. After that, gnome-shell doesn't start anymore, crashing in libgnome-desktop: [ 2085.503935] gnome-shell[9772]: segfault at 4 ip eb0eb4b1 sp ffc86bf0 error 6 in libgnome-desktop-3.so.7.0.0[eb0cb000+32000] The problem seems to be that gnome-shell 3.6 links to libgnome-desktop-3.so.4 (from G3.6) but the gir package loads libgnome-desktop-3.so.7 (from G3.7.90). This is just an example with shell and libgnome-desktop, but the problem likely applies in other cases. I wonder if there's a way to avoid this. Perhaps we could bump the version of the gir whenever the SONAME changes, so that we would have e.g. GnomeDesktop-3.0.typelib for G3.6, but GnomeDesktop-3.8.typelib for G3.8. I'm not quite sure if that would help or not, as I'm not familiar with introspection stuff. The idea is 'encode' the SONAME in the gir too, so that we can a) have multiple versions installed simultaneously, and b) the right version is loaded to avoid cases like this. Thoughts? Thanks, Emilio ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: 3.2: gjs/seed
On 21/04/11 01:12, Colin Walters wrote: > There are, however, nontrivial issues. First is that actually in good > news on the gjs front, a standalone Spidermonkey release was just made > recently, and I have a patch ready to use it in gjs: > https://bugzilla.gnome.org/show_bug.cgi?id=646369 > In contrast though, /usr/bin/seed appears to actually link to WebKit, > which would be a painful dependency to have for gnome-shell, since > it'd be insane to try using it inside the compositor process. This > may (hopefully) be fixable. It is, we just need to get JSC splitted as a standalone library: https://bugs.webkit.org/show_bug.cgi?id=19428 Cheers, Emilio ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Using .tar.xz only on ftp.gnome.org (was: install-module / ftp.gnome.org / master.gnome.org)
On 19/03/11 12:25, Emilio Pozuelo Monfort wrote: > On 19/03/11 11:19, Olav Vitters wrote: >> As a pre-warning, could you please ask the ftp-masters again to support >> .xz? > > They have included this item in their agenda for the meeting. I've told them > that GNOME plans to switch to .xz soon and that not allowing that in Debian > would mean we'd need to repackage upstream tarballs (which is bad). > > I'll let you know if/when they make any decisions. The meeting is over, and their summary on this point is: - For multiarch and XZ handling, we have asked for updates to python-apt in stable which will simplify adding these features. Assuming that the SRMs accept the update which the apt team are helpfully preparing for us, we'll add these as soon as we can get the package updated on franck. So I'd say .xz support will be in place in ~ 1 or 2 months. Definitely for GNOME 3.2, but hopefully way sooner. Cheers, Emilio ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Using .tar.xz only on ftp.gnome.org (was: install-module / ftp.gnome.org / master.gnome.org)
On 21/03/11 15:29, Olav Vitters wrote: > ATM I really like to switch to the new script (ftpadmin) before 3.0 as > it correctly handles NEWS files and .0 releases.. \o/ That always annoyed me. Thanks! Emilio ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Using .tar.xz only on ftp.gnome.org (was: install-module / ftp.gnome.org / master.gnome.org)
On 19/03/11 11:19, Olav Vitters wrote: > Note: breaking thread on purpose. > > On Wed, Mar 02, 2011 at 04:31:23PM +0100, Olav Vitters wrote: >> On Wed, Mar 02, 2011 at 03:15:34PM +, Emilio Pozuelo Monfort wrote: >>> From a Debian POV, we can't upload .xz upstream tarballs yet (dpkg supports >>> it, >>> but the ftp-masters don't allow it), though most likely that will change >>> soon. >> >> Could you ask when they'd allow that? And please mention we're >> considering switching. Don't want it to result in people compressing >> again though. > > I'm in the finishing stages to have all our scripts support .tar.xz > (install-module, release team scripts). Once that is complete, I plan to > send an 'intend to switch' announcement mail. > > As a pre-warning, could you please ask the ftp-masters again to support > .xz? They have included this item in their agenda for the meeting. I've told them that GNOME plans to switch to .xz soon and that not allowing that in Debian would mean we'd need to repackage upstream tarballs (which is bad). I'll let you know if/when they make any decisions. Cheers, Emilio ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: install-module / ftp.gnome.org / master.gnome.org
Hi, On 02/03/11 10:50, Olav Vitters wrote: > - gzip/bz2/lzma compression; lzma only? As has been said: lzma is deprecated in favor of xz, so it should be gzip/bz2/xz. There's no point in going to lzma anymore. >From a Debian POV, we can't upload .xz upstream tarballs yet (dpkg supports it, but the ftp-masters don't allow it), though most likely that will change soon. So .bz2 & .xz would be preferred for us to avoid recompressing tarballs. But we can do that if you decide to only support .xz, until we can upload those to the archive. Cheers, Emilio ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
telepathy-glib & telepathy-logger minimum dependencies
Hi, I've just updated telepathy-logger to 0.2.1 and telepathy-glib to 0.13.15 in the modulesets. telepathy-glib 0.14 (stable) will be released before GNOME 3.0, and this telepathy-logger bump should be the last one before 3.0 (it's an stable release, required by Empathy). Emilio ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: gnome-control-center network panel
Hi Richard, On 22/02/11 12:26, Richard Hughes wrote: > If you're using the network panel in gnome-control-center, you need to > be _running_ the 0.9 version of NetworkManager daemon. If you're > compiling with JHBuild, then you're probably compiling against 0.9 > already, but have a running 0.8 daemon and so the control panel will > be very bare. The API is quite different, and so a dialog is shown > warning the hapless user. Ideally distros like rawhide should be > shipping 0.9 pre-releases. Are there tarballs for NM 0.9 already? And if not, do you know the plans for the 0.9 release? Cheers, Emilio ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Bump telepathy-glib minimum version
On 28/01/11 00:16, Matthias Clasen wrote: > On Thu, Jan 27, 2011 at 6:47 PM, Emilio Pozuelo Monfort > wrote: >> I'd like to bump the minimum telepathy-glib requirement to 0.13.11, which we >> need for Empathy. It's currently at 0.13.9, and 0.13.x is the unstable series >> leading to the stable 0.14 release, which we'll want for GNOME 3.0 anyway. >> >> If nobody objects I'll go and bump it in a couple of days. > > Sounds good to me. Thanks, I've just updated the wiki and jhbuild. Cheers, Emilio ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Bump telepathy-glib minimum version
Hi, I'd like to bump the minimum telepathy-glib requirement to 0.13.11, which we need for Empathy. It's currently at 0.13.9, and 0.13.x is the unstable series leading to the stable 0.14 release, which we'll want for GNOME 3.0 anyway. If nobody objects I'll go and bump it in a couple of days. Cheers, Emilio ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: 2.91.5 status
On 11/01/11 17:58, Vincent Untz wrote: > I haven't tested anything at runtime, though, so maybe it's a > complete disaster ;-) We'll see tomorrow. gnome-shell 2.91.4 doesn't start with gtk+ 2.99. It's fixed in git, commit 2763d8dcc1311640744c353adf8c35f2bb86feef Cheers, Emilio ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Metacity towards GNOME 3.0
On 02/12/10 17:54, Owen Taylor wrote: Does this mean that libmetacity-private will also depend on GTK+ 3.0 ? Compiz currently uses this library to handle frame drawing from metacity themes and I need to know whether I need to update the deps there. Yes, that would be a consequence. (If we made it dual build then you'd have to handle both which would be no fun at all.) When switching to gtk+3, since the SONAME will need to change, maybe you could rename the library to libmetacity, since it doesn't seem to be private at all... :) Regards, Emilio ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Metacity towards GNOME 3.0
On 02/12/10 17:54, Owen Taylor wrote: On Thu, 2010-12-02 at 17:23 +0800, Sam Spilsbury wrote: - We could just make it require GTK+ 3.0. This is my suggestion - GNOME 3 is a GTK+ 3.0-based desktop. Metacity is the GNOME (fallback) window manager. GTK+ 3.0 will be released as a stable toolkit before Metacity 3.0 is released. If people need to Metacity build against older GTK+, the older tarballs aren't going to be removed from the website. If someone wants to use Metacity 3.0 in a legacy environment - on an older operating system - the GSettings requirement, which we can't get away from, would be a big problem. Hi Owen, Does this mean that libmetacity-private will also depend on GTK+ 3.0 ? Compiz currently uses this library to handle frame drawing from metacity themes and I need to know whether I need to update the deps there. Yes, that would be a consequence. (If we made it dual build then you'd have to handle both which would be no fun at all.) When switching to gtk+3, since the SONAME will need to change, maybe you could rename the library to libmetacity, since it doesn't seem to be private at all... :) Regards, Emilio ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: splitting up gnome-games
Hi, On 04/10/10 17:30, Colin Walters wrote: > I'd like to float the idea of splitting up gnome-games upstream into > separate git modules. The main rationale is that downstream, we want > separate binary packages; this is most convenient to do if upstream is > separate modules. Can't you just create several binary packages out of one source package? Regards, Emilio ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Versioned symbols for 3.0?
On 18/05/10 18:50, Patryk Zawadzki wrote: > The most important to us as a distribution is being able to > automatically maintain dependencies for libraries that add symbols > without changing their soname. For example g_malloc_n was introduced > in glib 2.24. > > We currently need to manually test each app linked to glib to find the > minimal glib version needed because just depending on the soname is > not enough. We could rely on application maintainers providin correct > versions in the configure files but 1) that's not always the case and > 2) glib's very own macros can introduce new dependencies at the > compilation time (for example after we upgraded to glib 2.24 > g_malloc_n was introduced to a number of applications that compiled > and worked with older glib releases). > > On the other hand we don't have to do this for glibc as rpm > automatically extract interface versions and glibc automatically gets > these provides: > > libc.so.6(GLIBC_2.0) > libc.so.6(GLIBC_2.1) > ... > libc.so.6(GLIBC_2.12) > > Now if a package uses a symbol from a versioned interface, rpm will > automatically add "Requires: libc.so.6(GLIBC_2.6)" without us having > to search through the history of API changes. I imagine the same thing > can be done (or already is done) for other packaging solutions (deb, > autopackage, zeroinstall etc.). In Debian we do this by having this information in a .symbols file in the package. When another package that uses that library is built, dpkg checks what symbols of that library it uses, and adds the dependency accordingly (e.g. if the package uses g_foo from 2.14 and g_bar from 2.18, the application will depend on glib >= 2.18). The .symbols file look like this[1] and is 'manually'[2] updated. Not saying that the proposed change is not useful though. Cheers, Emilio [1] http://svn.debian.org/viewsvn/pkg-gnome/desktop/unstable/glib2.0/debian/libglib2.0-0.symbols?revision=23409&view=markup [2] Where manually means applying a diff generated by dpkg ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GtkNotebook scrolling usability
On 11/03/10 00:25, Jason D. Clinton wrote: > On Wed, Mar 10, 2010 at 4:50 PM, Cody Russell wrote: >> He >> suggested that maybe there's a use for it in the case that you have a >> ton of notebook tabs open, but I'm not quite convinced. Just wanted to >> post on the lists and see if people have thoughts on this, otherwise I'm >> probably going to file a patch to either rip the feature out or at the >> very least make it so we can disable it. :) >> > > I don't recall where but I'm fairly sure I saw someone using that to flip > through open tabs in Epiphany. I like that feature, and use it in Epiphany too (and Liferea and probably everywhere there's a GtkNotebook). Emilio ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Reminder : do NOT hardcode deprecation flags in tarball / new tarballs NEEDED
On 10/03/10 19:05, Frederic Crozat wrote: > Since I'm the release team member taking care of 2.29.92 release, I'm > going to rant again against modules which are hardcoding deprecation > flags in their configure.in (or Makefile.am), even when building from > tarballs. Please, avoid that, it is killing us, since many released > modules are not building with latest gtk+ 2.19.7 (new deprecated added). > If you want to use deprecation flags, check in configure.in if you are > in a git checkout and enable them in that case, but do not enable them > by default in tarballs. This is also harmful to distributors as it means some packages will start to FTBFS when updating a different one (e.g. because it adds new deprecations). So full ACK. Cheers, Emilio ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Platform for Developer Documentation
On 07/03/10 22:16, Shaun McCance wrote: > I'm going to focus on the following programming languages: > > * C > * C++ > * Java > * JavaScript > * C# > * Perl > * Python > I'm going to begin sketching out the content plan for > the Platform Overview based on this. If I've forgotten > something, please tell me. If you feel strongly that > anything I mentioned should not be pushed, speak up. Looks like you forgot Vala. Cheers, Emilio ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Moving gconf schemas out of gnome-vfs2
On 29/01/10 15:02, Tomas Bzatek wrote: We're still shipping some gconf schemas within gnome-vfs2 which are used by variety of other Gnome components. Most notable are the default URL handlers, proxy settings and terminal stuff. Since gnome-vfs2 is already dead by this moment, would be great to move the schemas to the components which they belong to. There's an upstream bug for that, feel free to stop by and comment: https://bugzilla.gnome.org/show_bug.cgi?id=600686 We also need to do this for the other deprecated modules, such as libgnome. See https://bugzilla.gnome.org/show_bug.cgi?id=590774 Emilio ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: pysqlite2 external dependency
Hi, Andre Klapper wrote: > This is still valid: > http://git.gnome.org/browse/jhbuild/tree/modulesets/gnome-external-deps-2.30.modules > http://live.gnome.org/TwoPointTwentynine/ExternalDependencies Fred just fixed it: http://git.gnome.org/browse/jhbuild/commit/?id=be0fb97210250e4c9ca10f21e1e183c187784578 Cheers, Emilio ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
pysqlite2 external dependency
Hi, jhbuild lists pysqlite2 as a GNOME external dependency, although the wiki doesn't. It's only used by hamster-applet, which can also use the sqlite3 module shipped with Python >= 2.5 (and prefers it). Since we already require Python 2.5 as a minimum dependency, is it OK to remove pysqlite2 from the external dependencies? Cheers, Emilio signature.asc Description: OpenPGP digital signature ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Not proposing gnome-packagekit for 2.28
Richard Hughes wrote: > Anyway, if anyone has any great argument about why I shouldn't propose > gnome-packagekit for 2-29 (or why I should do it for 2-27) please > shout now. I'm also not sure whether to propose it for the desktop set > or something else. Ideas welcome. I was going to ask about the debconf support in PackageKit, but I just found [1] which seems to suggest it's being fixed. Is that right? Will any Debian policy compliant package work fine with PackageKit? I guess the solution is not KDE/Qt specific. If so that's good news. Cheers, Emilio [1] http://dantti.wordpress.com/2009/10/14/packagekit-and-the-road-to-debian/ signature.asc Description: OpenPGP digital signature ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: External dependency proposal: Vala
Andre Klapper wrote: > According to our rules only maintainers can propose their modules Even for external dependencies? Emilio signature.asc Description: OpenPGP digital signature ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Packages with no changelogs
Xan Lopez wrote: > 2009/9/26 Josselin Mouette : >> Le samedi 26 septembre 2009 à 12:27 +0100, Emmanuele Bassi a écrit : >>> on the serious side: auto-generation of ChangeLogs is all fine and >>> dandy, but distribution packagers should care about the NEWS files being >>> correct[0]; a NEWS file is usually much more readable than an old style >>> ChangeLog[1]. >> And generally I read the NEWS, but often I need more than that, and an >> appropriate ChangeLog is required. >> >> Furthermore, NEWS doesn’t comply with the GPL, which requires at least >> the modification dates. > > If I read GPL 2 correctly it says the files themselves should have > "prominent notices stating that you changed the files and the dates of > any change", so it would be interesting to know if you think we should > do that too. Or maybe that's going too far, a waste of time for the > developers and a duplication of information that is readily available > elsewhere. Like ChangeLogs. That's precisely the point, ChangeLogs are not readily available anymore in many tarballs since the migration to git. All we want is for them to be generated in the tarballs again. Cheers, Emilio signature.asc Description: OpenPGP digital signature ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: New module proposal: tracker
Vincent Untz wrote: > Le mardi 18 août 2009, à 17:47 +0100, Martyn Russell a écrit : >> On 18/08/09 17:44, Lennart Poettering wrote: >>> I don't think it would be a good idea to use GNOME solely as a vehicle >>> to make things more popular with other developers... >> Actually, we want to be in GNOME not only for availability but also >> to have a release schedule to run with. Right now we are doing >> things at our own speed and that can mean we miss some distro >> releases which we want to avoid. > > So, hrm, why not start right now to follow the GNOME release cycle? You > don't have tobe part of GNOME for this :-) And even then, there are official modules that don't follow the GNOME schedule signature.asc Description: OpenPGP digital signature ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Application names
William Jon McCann wrote: >2. We need to fix a lot of our desktop files to use Name and > GenericName correctly: GNOME Goal, tracker bug, Fedora wiki page. >- http://live.gnome.org/GnomeGoals/CorrectGenericName >- http://bugzilla.gnome.org/show_bug.cgi?id=588975 >- https://fedoraproject.org/wiki/Desktop/Whiteboards/ApplicationNames Also see http://www.gnome.org/~fpeters/reports/desktop_generic_name.html (the first three columns) Cheers, Emilio signature.asc Description: OpenPGP digital signature ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Application names
Luca Ferretti wrote: > #2 - Is the removal of GenericName ok for cross-desktop? > > You wrote "When Name is the same as GenericName, the GenericName > should be removed". A use cases for this are, for example, the > calculator and the file manager. What if both GNOME and KDE are > installed on the same system? We'll have 2 "Calculator" and two > "File Manager" with no ability to discriminate them? Shouldn't they have OnlyShowIn or NotShowIn set as appropriate anyway? Emilio signature.asc Description: OpenPGP digital signature ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
GConf schemas in deprecated libraries
Hi, I've reported bug 590774[1] against gnome-terminal. The problem is that it reads some defaults (monospace font) from GConf, but that schema is provided by libgnome. Since we're trying to get rid of libgnome (g-t got rid of it in 2.26), shouldn't the schemas be moved to another place, so that we can at some point get rid of libgnome completely? Cheers, Emilio [1] http://bugzilla.gnome.org/show_bug.cgi?id=590774 signature.asc Description: OpenPGP digital signature ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Applets? [was Re: Planning for GNOME 3.0]
Milan Bouchet-Valat wrote: > While I agree your proposal would be a great enhancement for most > applications that abuse of the notification area (e.g. music players), I > don't think that could fully replace applets. Applets like timerapplet > or sticky notes are different from standard applications in the sense > that you don't work with them as a full task, but only keep them in the > background to be easily accessible, while you actually use them for a > very short period. > > The point with them is that the ratio (time running)/(time use) is very > low compared with e.g. a text processor. Thus, you need them not to take > too much space on the screen, not even, as you suggested, stacked in a > corner by the window manager. I'd argue that the best place to put them > is on a separate layer à la dashboard (Apple), or directly on the > desktop. This layer could be accessed with a button in the top panel, > somewhere or in the overlay. Many "widgets" of this kind exist, see > Screenlets, Superkaramba, or Google gadgets, or Plasmoids. A simple way > of reintroducing applets in a "correct" way would be to support e.g. > Screenlets in an overlay: replacements for Tomboy already exist in that > framework, which is AFAIK compatible with other widget formats. > > At least, that's really how I consider we could get rid of the clutter > on the main screen, which is distracting us with icons we don't need to > be always visible. I like the proposed solution that the panel launchers would somehow become a dock. e.g. for Tomboy or Hamster Applet, you have the icon launcher. If you click on it, the app is opened. If you click on it again, it's closed. That could be achieved with single-instance applications (libunique), for example (when you try to launch it again, the instance is closed). For many cases, I can imagine such a workflow would be fine. It wouldn't solve all of them though, for example you don't want system-monitor to be a launcher, but rather to see the system activity IRL. Another benefit of this is that a) your applet doesn't need to be started up on login, and b) you don't have it running everytime. Of course, you need it to be quick to start up. But if it doesn't for such small applications, it's a big fail IMHO. Best regards, Emilio signature.asc Description: OpenPGP digital signature ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: libsoup branched for 2.26
Hi Dan, Dan Winship wrote: > Plans for 2.28 are not nailed down, but are mostly being driven by > WebKit at this point (with bug reports, feature requests, and patches > coming from both the Epiphany and Midori developers). Features currently > in progress include better Content-Type sniffing (kov), caching (xan), > and Content-Encoding (ie, gzip) support (Company). Are there any plans for IDN support for this cycle (bug #548287)? Cheers, Emilio signature.asc Description: OpenPGP digital signature ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Debian-specific patches for the GNOME packages
Murray Cumming wrote: > On Thu, 2008-09-11 at 10:54 +0200, Josselin Mouette wrote: >> Hi guys, >> >> it was already requested by a few people in the GNOME community to have >> a quick access to all patches distros apply. Since we now have a much >> better interface than the direct access to our svn repository, I think >> this might be of interest. >> >> So in short, what you might be looking for is here: >> http://patch-tracking.debian.net/email/[EMAIL PROTECTED] > > That seems to include "patches" that just add the debian packaging > files, so it's hard to see what really has a real patch. For instance, I > can't see any actual code changes here: > http://patch-tracking.debian.net/patch/debianonly/view/gtkmm2.4/1:2.12.7-1 > That's because it contains no patches. If it did, there would be a "series style patches" section. Look for example at nautilus: http://patch-tracking.debian.net/package/nautilus/2.20.0-6 Cheers, Emilio signature.asc Description: OpenPGP digital signature ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: [Usability] application names in the application menu
Matthew Paul Thomas wrote: > If a program has a name obviously related to what it does, *or* lots of > marketing, you're fine. But if you're missing both, people will have > trouble working out what the program is for. Even then, an obvious name may only work for English. You will never see translated Rhythmbox as "Caja de ritmos" (which sounds too ugly). Same for every other application. So I think having both the application name and what it's for (as "Epiphany web browser") makes sense, because of this and other arguments mentioned on the thread (as e.g. if you install several applications of the same purpose). Cheers, Emilio signature.asc Description: OpenPGP digital signature ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
