Re: Bug#969321: transition: GNOME 3.38, libmutter-7-0
Control: tags -1 confirmed Hi Simon, On 25/09/2020 00:09, Simon McVittie wrote: > budgie-desktop should be the only non-GNOME-team package directly affected > by this, apart from gnome-shell-xrdesktop which is not in testing anyway > (and needs to move to contrib). budgie needs at least a rebuild and maybe > source changes, but there's already a version built against libmutter-7-0 > waiting in experimental. > > Ubuntu already did this transition. > > As I said before, some GNOME Shell extensions will almost certainly break, > but we don't know which ones (I checked the few I maintain personally and > they seem OK). I think we should be fairly trigger-happy about removing > these from testing if they're broken or uninstallable. Let's go ahead with the mutter/shell transition. >> * evolution-data-server has an ABI break, which has already made its way >> through NEW >> - >> https://release.debian.org/transitions/html/auto-evolution-data-server.html > > I think we can perhaps defer this one until after mutter, Shell and > the other core packages have gone through? Or we could entangle them, > whichever you'd prefer. There are more packages involved and I don't know > the status of all of them: Sebastien Bacher would probably know better. Depending on the status of the rdeps, I may be fine with entangling them. But if you prefer to do one after the other that's alright too. Cheers, Emilio
Re: Bug#954422: transition: GNOME 3.36
On 16/04/2020 10:08, Simon McVittie wrote: > On Fri, 10 Apr 2020 at 12:27:04 +0200, Emilio Pozuelo Monfort wrote: >> Let's go ahead. > > gnome-desktop3 has migrated, but gnome-shell and mutter have not. We're > now getting reports that GNOME Shell in testing is crashing because it > indirectly loads more than one copy of gnome-desktop3. > > Would it be possible to binNMU affected packages *in testing*, so that > everything is using the same version even before they migrate? (I'm > not sure whether that will work - they might FTBFS - but it seems worth > a try.) > > Dependent packages that are not in sync between testing and unstable: > > - mutter > - gnome-shell > - gnome-weather (for completeness, but probably doesn't matter here) > > Or is there something else we should have done to make this transition > go more smoothly, like having gnome-desktop3 3.36.x Breaks older > gnome-shell and mutter? > > Giving libgnome-desktop-3-19 a Conflicts on -17 and -18 doesn't seem > great because it defeats part of the purpose of the SONAMEs, but perhaps > that would have been the lesser evil? > > Versioned symbols in gnome-desktop3 would not help us here, because the > GObject type system is a flat global namespace. > > If you would prefer to solve this by getting GNOME Shell 3.36.x > into testing ASAP: it looks as though gnome-shell 3.36 is ready to > migrate if gnome-shell-xrdesktop, gnome-shell-extension-dashtodock, > gnome-shell-extension-easyscreencast are temporarily removed, and > gnome-shell-extension-appindicator is aged by at least a day. I've gone that route. If all goes well, gnome-shell/mutter should migrate in the next britney run at 1600Z. Cheers, Emilio
Re: Bug#954422: transition: GNOME 3.36
On 15/04/2020 09:53, Simon McVittie wrote: > Control: tags -1 - moreinfo > > On Sat, 11 Apr 2020 at 13:42:46 +0100, Simon McVittie wrote: >> https://release.debian.org/transitions/html/auto-gnome-desktop3.html >> - Should be ready to start binNMUs >> - Please binNMU xdg-desktop-portal-gtk in experimental too >> - No point in binNMUing budgie-desktop due to the mutter transition >> - No point in binNMUing gnome-shell-xrdesktop due to the mutter transition > > In case it wasn't clear: please binNMU when convenient. Sorry for the delay. Scheduled now. Cheers, Emilio
Re: Bug#954422: transition: GNOME 3.36
Control: tags -1 confirmed On 08/04/2020 14:22, Sebastian Ramacher wrote: > On 2020-04-08 11:46:59 +0100, Simon McVittie wrote: >> On 21/03/2020 13:17, Simon McVittie wrote: It would probably make most sense to treat gnome-desktop3 and mutter as a single transition, as we have often done in the past: upstream will not have tested arbitrary mixtures of 3.34 and 3.36. >> >> Progress on this: >> >> After chasing regressions for the last few days, I think we have Shell >> in a good state to consider doing this transition. This would involve >> uploading the following experimental GNOME packages to unstable as a batch: >> >> * gnome-desktop3 >> * gjs >> * mutter >> * gnome-shell >> * gnome-shell-extensions >> >> Ubuntu have already done this transition for 20.04 'focal', so I hope >> the Ubuntu people in the GNOME team can give us an idea of the level of >> breakage without us having to do our own test-rebuild in Debian. >> I'm told the only significant porting work needed in Ubuntu was in Unity. >> >> gnome-desktop3 ABI breaks have mostly been handled via binNMUs in the >> past, without being particularly problematic. >> >> budgie will need rebuilding against the new mutter, but seems to have >> already been patched to cope with either the old or new API/ABI. >> >> gnome-shell-xrdesktop (a "friendly fork" of gnome-shell with an >> experimental 3D UI for VR headsets) will need either updating to 3.36.x >> to match (#956147) or removing from testing for a while. I am not able >> to test this, and I suspect the rest of the GNOME team are in the same >> situation; I don't think we should let gnome-shell-xrdesktop (popcon: 0) >> hold back gnome-shell (popcon: 37K votes). > > The xrdesktop stack is currently doing its own transition > (libgulkan-0.13-0 -> libgulkan-0.14-0, libgxr-0.13-0 -> libgxr-0.14-0, > and soon the same for libxrdesktop). It's currently blocked on xrdesktop > in NEW. Let's go ahead. The situation looks to be in a good state. Extensions have always been treated this way, on a best effort basis during the transitions, so we'll keep as many as we can but if any of them aren't compatible and don't get updated in time we'll drop them from testing until they are fixed. The xrdesktop/gulkan transition looks to be almost done now, but even if it wasn't, the only point of entanglement is gnome-shell-xrdesktop which worst case can be temporarily removed. Cheers, Emilio
Re: Bug#906016: transition: gjs built with mozjs60
On 08/03/2019 10:07, Simon McVittie wrote:
> Control: block -1 by 923694
>
> On Sat, 02 Mar 2019 at 22:21:31 +, Simon McVittie wrote:
>> On Tue, 05 Feb 2019 at 10:16:56 +, Simon McVittie wrote:
> * Require task-gnome-desktop to be installable on s390x, but modify
> meta-gnome3 so that on s390x, gnome-core installs something that is not
> the full GNOME 3 desktop used on other architectures, for example
> the GNOME-2-derived gnome-session-flashback
>>
>> In the absence of other progress, I've staged this in git. I'll release
>> it soon if nobody else in the team gets there first.
>
> This has now reached testing, but gjs is blocked by gnome-documents:
>
> trying: polari gjs gnome-shell gdm3 gnome-sushi
> skipped: polari gjs gnome-shell gdm3 gnome-sushi (0, 1, 25)
> got: 33+0: a-1:a-0:a-0:a-0:i-30:m-0:m-0:m-0:p-0:s-2
> * s390x: gnome-documents
>
> gnome-documents already has an unblock request.
>
> If that unblock is rejected or if the release team are not sure about
> it yet, the gnome-documents_3.30.0-1_s390x binary could be forcibly
> removed from testing, which I think would let the gjs family migrate.
> `dak rm -R -n -s testing -a s390x gnome-documents` says nothing else on
> s390x depends on gnome-documents any more.
I unblocked and aged gnome-{documents,books}, my britney test run has gjs
migrating now, so it should happen in the next few hours.
Cheers,
Emilio
Re: Bug#906016: transition: gjs built with mozjs60
On 08/02/2019 17:21, Simon McVittie wrote: > On Fri, 08 Feb 2019 at 16:48:52 +0100, Cyril Brulebois wrote: >> I'm not sure how to hide a particular entry on a particular arch; I'm >> not a tasksel expert and won't be one in the next 5 minutes. But it >> seems to me the immediate concern was about the default desktop anyway, >> which shouldn't be an issue in the first place because of this >> default_desktop shell function? > > The immediate concern is that gjs and friends don't migrate to testing, > because the release team's migration infrastructure asserts that all > task packages remain installable on all release architectures, and that > isn't true any more for task-gnome-desktop on s390x. > > Do you consider it to be OK that non-default desktops can be uninstallable > on s390x? If so, hopefully the release team can relax that check. My worry if I were to do that is that the installer would still offer to install GNOME on s390x, and I don't know what would happen if one chose that (I suppose apt would realise it's uninstallable and give a proper error, but maybe things would explode). So if we're going to make task-gnome-desktop uninstallable there, maybe the installer shouldn't offer to install it, and that needs changes somewhere in tasksel or d-i. Cheers, Emilio
Re: Bug#906016: transition: gjs built with mozjs60
Hi, On 05/02/2019 11:16, Simon McVittie wrote: > Please could we have a decision on this in plenty of time before the freeze? > Given the upstream GC improvements aimed at mitigating or solving "the memory > leak problem" in gjs 1.54.x, I am not comfortable with releasing buster with > gjs 1.52.x (which has a backport of those changes done by a developer who does > not have in-depth knowledge of gjs, namely me); so I would like to ask for a > freeze exception to complete this transition. Yes, it is my intention to finish this. > On Thu, 17 Jan 2019 at 10:25:01 +0100, Emilio Pozuelo Monfort wrote: >> On 17/12/2018 15:56, Simon McVittie wrote: >>> The options I can see are: >>> >>> * Accept that task-gnome-desktop is not going to be installable on s390x. >>> Change the testing migration scripts to skip installability testing for >>> that package on s390x, or ignore the fact that it fails. Optionally >>> change tasksel to make task-gnome-desktop Architecture: any, and give it >>> some Build-Depends-Arch that are not satisfiable on s390x so that it will >>> not be built there. >>> - s390x d-i users will not be able to install a GNOME desktop. Hopefully >>> the menu item would not appear, and task-desktop would pick up the >>> second-preference desktop instead, which currently seems to be XFCE? >>> - Risk: is it possible to ignore uninstallability of task-gnome-desktop >>> without ignoring uninstallability of other task packages? > > I would prefer this option if possible: the GNOME desktop is clearly not > intended for use on mainframes, and I doubt anyone is seriously trying to use > it there (as opposed to individual GNOME apps in a remote-desktop framework, > which might be something that people do). However, it requires action from the > release team and d-i maintainers. Cyril, can we do something to not offer task-gnome-desktop on s390x? Does that need changes in d-i or tasksel? >>> * Require task-gnome-desktop to be installable on s390x, but modify >>> meta-gnome3 so that on s390x, gnome-core installs something that is not >>> the full GNOME 3 desktop used on other architectures, for example >>> the GNOME-2-derived gnome-session-flashback instead of gnome-session and >>> gnome-shell, and lightdm instead of gdm3. >>> - s390x users will not get the same GNOME desktop everyone else does. >>> - Risk: if GNOME Flashback becomes unsupportable in some future release >>> (it's a GNOME 2 derivative a bit like MATE, although without using >>> forks of the apps, and most upstream and downstream GNOME maintainers >>> don't use or maintain it), we're back where we started. > > With the freeze approaching fast, if we can't have a solution that requires > action to be taken outside the GNOME team, this is probably the best thing > that > the GNOME team can do unilaterally. An untested git branch for this: > https://salsa.debian.org/gnome-team/meta-gnome3/merge_requests/3 Alternatively, this is probably the way to go. Cheers, Emilio
Re: Uploading 3.32 & pre-releases to experimental
On 16/01/2019 17:20, Iain Lane wrote: > I asked on IRC, but this might be more durable for those who weren't > watching at the time. > > I'd like to upload 3.32 to experimental. Would this be a problem, given > the freeze and that it wouldn't be going into buster? I'm not going to > be touching unstable with this work, so testing migration wouldn't be > affected in that sense. That shouldn't be a problem. Any buster-related changes can go via sid, so experimental could be used for that. Cheers, Emilio
Re: Bug#906016: transition: gjs built with mozjs60
Hi Cyril,
On 17/12/2018 15:56, Simon McVittie wrote:
> On Thu, 13 Dec 2018 at 17:00:21 +0100, Emilio Pozuelo Monfort wrote:
>> On 13/12/2018 16:58, Emilio Pozuelo Monfort wrote:
>>> task-pkgs-are-installable-faux depends on task-gnome-desktop, which depends
>>> on
>>> gnome, which is removed from s390x. I'm not comfortable breaking that, you'd
>>> need an ack from Cyril for that. The alternative would be to keep building
>>> gnome from src:meta-gnome3 on s390x but removing the deps that are not
>>> available,
>>> or to apply the proposed mozjs patches from upstream to restore support on
>>> s390x
>>> if those are enough.
>>
>> Another option is to restrict the task-gnome-desktop check to !s390x. But
>> again
>> I'd like an ack from Cyril before doing that in case d-i needs to be updated
>> to
>> not offer that on s390x.
>
> For context for those newly Cc'd:
>
> We have this dependency chain:
>
> task-gnome-desktop -> gnome-core -> gnome-shell -> gjs -> mozjs{52,60}
>
> gjs recently switched from mozjs52 to mozjs60, and mozjs60 doesn't work
> on s390x (#909536; about 80% of its tests fail, which means I have no
> confidence that the resulting binaries would be useful or usable if
> we ignored the test failures). As far as I know, the best patches we
> have for that are the ones Julien Cristau tested, which might be part
> of a solution but are not sufficient on their own to make a reasonable
> proportion of the tests pass. (Julien, please correct me if I'm wrong?)
>
> The GNOME team and the release team both seem to be willing to declare
> that the "full-fat" GNOME desktop will not be available on s390x
> machines, which are very conspicuously not available in a desktop or
> laptop form factor :-) I'm fairly sure that GNOME and Mozilla upstream
> have no interest in supporting s390x mainframes either. As a result we
> have arranged for all the JavaScript-based GNOME packages (most notably
> gnome-shell), and the gnome-core and gnome metapackages, to not be built
> on s390x. However, this leaves us with an important task package that
> isn't installable on a release architecture, causing migration to fail.
>
> I suspect gnome-shell may have never worked acceptably on s390x in any
> case, since mainframes are not noted for their 3D graphics hardware,
> and s390x is not currently whitelisted to build the llvmpipe software
> renderer in mesa's debian/rules (I believe the Mesa maintainers are
> willing to enable llvmpipe on new architectures after a porter has tested
> it and told them it works, so a s390x porter could usefully try that out).
>
> The options I can see are:
>
> * Accept that task-gnome-desktop is not going to be installable on s390x.
> Change the testing migration scripts to skip installability testing for
> that package on s390x, or ignore the fact that it fails. Optionally
> change tasksel to make task-gnome-desktop Architecture: any, and give it
> some Build-Depends-Arch that are not satisfiable on s390x so that it will
> not be built there.
> - s390x d-i users will not be able to install a GNOME desktop. Hopefully
> the menu item would not appear, and task-desktop would pick up the
> second-preference desktop instead, which currently seems to be XFCE?
> - Risk: is it possible to ignore uninstallability of task-gnome-desktop
> without ignoring uninstallability of other task packages?
>
> * Require task-gnome-desktop to be installable on s390x, but modify
> meta-gnome3 so that on s390x, gnome-core installs something that is not
> the full GNOME 3 desktop used on other architectures, for example
> the GNOME-2-derived gnome-session-flashback instead of gnome-session and
> gnome-shell, and lightdm instead of gdm3.
> - s390x users will not get the same GNOME desktop everyone else does.
> - Risk: if GNOME Flashback becomes unsupportable in some future release
> (it's a GNOME 2 derivative a bit like MATE, although without using
> forks of the apps, and most upstream and downstream GNOME maintainers
> don't use or maintain it), we're back where we started.
>
> * Require task-gnome-desktop to be installable on s390x, but modify
> meta-gnome3 so that on s390x, gnome-core doesn't install a whole desktop
> enviroment at all, just the GNOME applications.
> - s390x users will not get a GNOME desktop at all.
> - Risk: this is not what the user asked for or expected.
>
> * Require task-gnome-desktop to be installable on s390x, but modify
> either tasksel or meta-gnome3 so that on s390x, task-gnome-desktop
> installs some GNOME-derived but non-GNOME desktop environment like MATE.
> - s
Re: Which team is best for team-maintaining libepoxy package ?
On 16/10/2018 22:05, Michael Biebl wrote: > Am 16.10.18 um 22:01 schrieb Michael Biebl: >> Am 16.10.18 um 21:53 schrieb Jeremy Bicha: >>> On Tue, Oct 16, 2018 at 2:37 PM Jérémy Lal wrote: libepoxy is needed by both KDE and GNOME packages. What's the best team to maintain it ? >>> >>> I guess we've been using https://salsa.debian.org/utopia-team for >>> cross-desktop stuff. >>> >>> It might make sense to merge that team with >>> https://salsa.debian.org/freedesktop-team even if much of the Utopia >>> stuff isn't actually hosted on freedesktop.org . >>> >>> I only recently realized that the Utopia team's name derives from >>> Project Utopia, an initiative which hasn't been around for several >>> years. >> >> This is correct. The utopia name mainly has nostalgic value (it was >> relevant when hal still was a thing) but does not actually describe any >> current efforts. >> That said, it's also very unspecific, which makes it useful as an >> umbrella if a thing is not strictly GNOME, fdo, ... specific. > > Fwiw, I wouldn't mind if pkg-fdo and pkg-utopia would be merged (but I > don't have a good suggestion for a different name). > pkg-fdo afaics is pretty much dormant at this point, whereas pkg-utopia > is still actively used for stuff like dbus, network-manager, udisks, > upower, etc. There are a few things actively maintained in freedesktop-team, e.g. poppler, fontconfig, geoclue, desktop-file-utils... (FSVO active, given some of these only receive seldom updates upstream). But I would be happy if these two were merged. As for libepoxy, it could go in utopia-team, or even in xorg-team. Cheers, Emilio
Re: Change Maintainer email for all Debian GNOME packages
On 10/12/17 01:57, Jeremy Bicha wrote: > According to the schedule [1], all Alioth emails will stop accepting > new mail February 1, less than 8 weeks from now. I thought there were plans to keep the lists working. Am I maybe misremembering? Cheers, Emilio
Re: RFC: Making gir1.2-* bundles Provide all their canonical names
On 04/11/17 16:19, Simon McVittie wrote: > On Sat, 04 Nov 2017 at 16:09:28 +0100, Michael Biebl wrote: >> Am 02.11.2017 um 16:33 schrieb Simon McVittie: >>> I'm tempted to modify the Lintian check to do this: >>> >>> * If gir1.2-foo-1.0 contains Bar-2.0.typelib and has >>> Provides: gir1.2-bar-2.0, then don't emit >>> typelib-package-name-does-not-match for it >>> >>> * If libfoo-dev contains Bar-2.0.gir and Depends on gir1.2-foo-1.0, >>> and gir1.2-foo-1.0 is being processed in the same batch of packages, >>> and gir1.2-foo-1.0 has Provides: gir1.2-bar-2.0, then don't emit >>> gir-missing-typelib-dependency for it >> >> What I'm missing is, what we should recommend rdeps to do: >> If a package say requires TrackerControl-2.0, should it depend on >> gir1.2-tracker-2.0 or the virtual gir1.2-trackercontrol-2.0? > > Either seems fine, particularly now that we have versioned Provides. > Using the more precise dependency (gir1.2-trackercontrol-2.0) makes > the dependency graph a little more complex for apt to disentangle, but > means we would be free to split gir1.2-tracker-2.0 with a minimum of > Breaks in future. > >> If the latter, how would we enforce, that users depend on the "right" >> package name? > > We don't currently have a way to enforce correct/sufficient dependencies > for users of g-i via Lintian or similar (we can't easily tell which g-i > modules are used by Python or JavaScript code, and whether they're > conditional or mandatory) so I don't think this is a regression. We could update dh_girepository to generate dependencies on the provided packages when that makes sense. That won't help with applications as you say, but it will help with gir package dependencies. Cheers, Emilio
Re: unstable/sid: libgtk-3-0 and libgtk-3-0-dbg
On 30/01/17 16:19, Kevin Connor Arpe wrote: > Emilio, > > Thanks for the quick reply. > > I tried to follow instructions from this page: > https://wiki.debian.org/HowToGetABacktrace > ... to rebuild package libgtk-3-0, but failed with error. > > root> DEB_BUILD_OPTIONS="nostrip noopt" fakeroot apt-get -b source libgtk-3-0 You shouldn't do the build as root. Cheers, Emilio
Re: unstable/sid: libgtk-3-0 and libgtk-3-0-dbg
On 30/01/17 13:18, Kevin Connor Arpe wrote: > Hello, > > I am an unstable/sid user on a vanilla x86-64 PC. > > I am trying to debug some app code that uses libgtk+ 3. I would be > very helpful to also have debug symbols for this library. > > My libgtk-3-0 is currently 3.22.7-2. Using aptitude, I tried to add > libgtk-3-0-dbg (3.4.2.7+deb7u1). However, I get a conflict error > message requesting me to downgrade my libgtk-3-0... which is nearly > nuclear. =] > > Is it difficult to get libgtk-3-0-dbg up to 3.22.7-2? You want libgtk-3-0-dbgsym from the debug archive. See https://wiki.debian.org/AutomaticDebugPackages for how to enable it. Cheers, Emilio
Re: Remove gnome-icon-theme and gnome-icon-theme-symbolic from the default installation
On 20/05/16 18:53, Laurent Bigonville wrote: > Hello, > > ATM there are some applications depending explicitly against gnome-icon-theme > or > gnome-icon-theme-symbolic packages. > > I think that these could be dropped from the default installation (I'm pretty > sure that the cd team will be happy with that). > > So the question is, are we simply dropping the icon theme dependency or are we > replacing it with a dependency against adwaita-icon-theme (or maybe even > adwaita-icon-theme | $some_provide)? The gnome-core metapackage already pulls > adwaita-icon-theme. > > I personally would drop all references to an icon theme (including > adwaita-icon-theme) and let the metapackage pulls it > > Any thoughts about this? Removing them altogether sounds good to me. Cheers, Emilio
Re: Enabling accessibility stack by default in Gtk2
On 30/08/15 18:19, Samuel Thibault wrote: > Hello, > > As discussed at DebConf [1,2,3], we would like to make the accessibility > stack enabled by default, so that all a user who needs it has to do is > just to start orca (while at the moment she has to find an option in > the control panel, and logout/login again, thus closing all running > applications...). > > This is actually already the case for Gtk3-based applications, we would > like to enable it for Gtk2-based applications too. I feel very safe > about this since the accessibility stack has been maturing in Gtk2 for a > decade now. > > The way I see it is simply by making the libatk-adaptor package add gail > and atk-bridge to GTK_MODULES from a script in /etc/X11/Xsession.d. > > Is it OK with GTK people? Sounds good to me. If problems arise, there's time to fix them or revert the change (hopefully the former). Cheers, Emilio
Re: jessie: Some GTK apps display svg pixmaps as giant icons
On 09/11/14 17:03, Felix Natter wrote: Dear gtk-gnome-maintainers, there is a bug in GTK(?) applications (nautilus, pavucontrol, probably more) where (svg?) icons are way too large in current jessie: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=765069 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=768256 It is easily reproducible by installing vim-gtk, creating a .txt file and selecting Open with- ... in nautilus for that file. (the vim icon will be huge). Alternatively, see screenshot of pavucontrol with a running scummvm session: http://www2.inf.fh-brs.de/~fnatte2s/pavucontrol-large-icon.png I have commented 765069 (nautilus) and 768256 (vim-gui-common) but does anybody think this should be reported against GTK? Apparently this was an intentional change in GTK+ 3.14, see https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=765069#49 I haven't looked at the impact of it and whether it's reasonable and feasible to revert it for Jessie. For now, it's probably best to file bugs for the applications that broke. Emilio -- To UNSUBSCRIBE, email to debian-gtk-gnome-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/5465b541.3020...@debian.org
Re: Bug#766388: RFP: gnome-initial-setup -- bootstrapping after installation
On 22/10/14 20:27, Changwoo Ryu wrote: Package: wnpp Severity: wishlist * Package name: gnome-initial-setup Version : 3.14.1 Upstream Author : * URL : https://wiki.gnome.org/Design/OS/InitialSetup * License : GPL-2+ Programming Lang: C Description : bootstrapping after installation This is part of GNOME release since 3.10. I think this can be nice addition to the empty GNOME screen after the installation. gdm should launch this application in the first boot situation. This wouldn't be very useful since all/most of the setup is done by d-i. Some integration would be needed, so that the installer defers the setup so that gnome-initial-setup can do it. I believe Laurent has investigated this. Emilio -- To UNSUBSCRIBE, email to debian-gtk-gnome-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/5448d284.9020...@debian.org
Re: Reverting to GNOME for jessie's default desktop
On 08/08/14 00:29, Don Armstrong wrote: On Thu, 07 Aug 2014, Jordi Mallach wrote: Well, it's roughly that time. :) So I'd like to plainly request GNOME is reinstated as the default desktop environment for a number of reasons. One of the reasons put forward for switching to Xfce was size on the installation images; could you (and/or debian-cd) address this? Specifically: 1) Would you want the default CD/DVD image to use a GNOME even if GNOME was unable to fit on a single image? I think the first CD/DVD should have whatever we choose as the default. 2) Would the GNOME team consider a less-complete DE for cases where image size is a restriction? Yes. If there wasn't enough space, we could drop some not very important modules (e.g. a few games), try a stronger compression ratio, symlink /usr/share/doc directories... We'd need some numbers here but we could work something out. Cheers, Emilio -- To UNSUBSCRIBE, email to debian-gtk-gnome-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/53e49467.5010...@debian.org
Re: Packaging the new WebKitGTK+ 2.6 series
On 06/08/14 13:25, Alberto Garcia wrote: On Tue, Aug 05, 2014 at 12:14:13AM +0200, Emilio Pozuelo Monfort wrote: An ITP is not needed. After all, this is just a new release of an existing package, with a different src name for technical reasons. Ok Opinions? Comments? Sounds good! Let me know if you want me to take a look at your changes. I can't work on this much until next month, but I can at least review it if that's needed. I'm making some tests, and I'll probably have something ready during this week. I guess we can use the same git repo for both packages? Yeah, that should be fine. We can use webkitgtk-2.6 for the upstream branch and unstable-webkit2gtk or just webkit2gtk or something else for the debian branch. Cheers, Emilio -- To UNSUBSCRIBE, email to debian-gtk-gnome-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/53e2128a.2050...@debian.org
Re: Packaging the new WebKitGTK+ 2.6 series
On 04/08/14 15:20, Alberto Garcia wrote: WebKitGTK+ 2.5.1 has just been published. This is the first development release of the upcoming 2.6 series. WebKitGTK+ has two APIs: the classic one and the more recent WebKit2. The classic one is now often referred to as WebKit1. WebKit1 supports GTK+2 and GTK+3, while WebKit2 only supports GTK+3. In Debian we have packages for all three cases: libwebkitgtk-1.0-0(WK1, GTK2) libwebkitgtk-3.0-0(WK1, GTK3) libwebkit2gtk-3.0-25 (WK2, GTK3) The most important change of this new series is the removal of the WebKit1 API. Bugfix releases of the 2.4.x series will be made for some time, but otherwise it's expected that applications switch to WebKit2 if they want to use the newest developments. Here's a blog post summarizing the situation: http://blogs.igalia.com/carlosgc/2014/08/01/webkitgtk-2-5-1-good-bye-webkit1/ Although WebKit1 is formally deprecated, there is still a significant number of programs using it (midori, banshee, xxxterm, shotwell, liferea, evolution, ...) so we need to keep the old packages around. Yes. I started filing bugs against webkit1 rdeps. I only did the python-webkit rdeps so far, need to do the rest. So we need to package both series separately (like we already do with e.g. gtk+2.0 and gtk+3.0), we could have a new webkit2gtk package with the new series. If I'm not wrong this needs a new ITP bug, right? An ITP is not needed. After all, this is just a new release of an existing package, with a different src name for technical reasons. The ITP won't hurt though, so feel free to file one. I also thought of renaming it to src:webkit2gtk, fwiw :-) Note also that the ABI has changed, so applications need to be rebuilt against the new series (there will be libwebkit2gtk-4.0-XX). Yeah. When libwebkit2gtk-3.0 has no rdeps, we can remove it and keep src:webkitgtk building webkit1 only (until that can also be removed). If all this looks fine to you, I can prepare the ITP one of these days. Opinions? Comments? Sounds good! Let me know if you want me to take a look at your changes. I can't work on this much until next month, but I can at least review it if that's needed. Cheers, Emilio -- To UNSUBSCRIBE, email to debian-gtk-gnome-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/53e005b5.6090...@debian.org
Re: Status of GNOME 3.10 in Debian?
On 11/06/14 11:45, Xavier Bestel wrote: On Sat, 05 Apr 2014 Emilio wrote: we should have all of 3.12 in testing/unstable this month. Which month ? $cur_month :) More seriously, we are blocked on a upower transition. Emilio -- To UNSUBSCRIBE, email to debian-gtk-gnome-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/53982748.2000...@debian.org
Re: Problem with the two audio devices
On 22/05/14 11:00, Bastian Venthur wrote: Hi, since a couple of weeks, I have two audio devices to choose for audio output. One is Speakers and the other is Analog Output (translated from German). The problem is, that I have to switch very often between the two of them, depending if I have my laptop in the docking station, the headphones in or just using it as is -- one output will produce output and the other will not. Before, I never had to switch anything and it always worked. Is there a way to tell Gnome (I suspect it is a Gnome issue since it started AFAIK with 3.8 or 3.12) to combine the two, Or at least do something automatically? From my point of view the laptop should have only one output device. I have exactly the same issue with my x230. When docking it, I have to manually change the output. It was working fine with 3.8 a while ago but is now broken, still in 3.8. Could have been a kernel regression, or pulseaudio. I haven't investigated it yet though. Cheers, Emilio -- To UNSUBSCRIBE, email to debian-gtk-gnome-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/537dc05b.70...@debian.org
Re: Bug#748591: RFS: gtkspellmm/3.0.3+dfsg-1 [ITP]
On 20/05/14 01:38, Vincent Cheng wrote: Hi Philip, On Sun, May 18, 2014 at 10:07 AM, Philip Rinn ri...@inventati.org wrote: Package: sponsorship-requests Severity: wishlist Dear mentors, I am looking for a sponsor for my package gtkspellmm. This package is a dependency of gimagereader, a GTK front-end for tesseract-ocr, which I also package. * Package name: gtkspellmm Version : 3.0.3+dfsg-1 Upstream Author : Sandro Mani manisan...@gmail.com * URL : http://gtkspell.sourceforge.net * License : GPL2+ Section : libs It builds those binary packages: libgtkspellmm-3.0-0 - C++ wrapper library for GtkSpell (shared libraries) libgtkspellmm-3.0-dev - C++ wrapper library for GtkSpell (development files) libgtkspellmm-3.0-doc - C++ wrappers for GtkSpell (documentation) To access further information about this package, please visit the following URL: http://mentors.debian.net/package/gtkspellmm Alternatively, one can download the package with dget using this command: dget -x http://mentors.debian.net/debian/pool/main/g/gtkspellmm/gtkspellmm_3.0.3+dfsg-1.dsc There is also a git repository in collab-maint: http://anonscm.debian.org/gitweb/?p=collab-maint/gtkspellmm.git;a=summary The package is Lintian clean but as it's my first library I'd be happy to get some feedback. Have you tried contacting the Debian GNOME team [1] (which maintains similar packages [2]) to see if anyone might be interested in your package? It's generally a lot easier to find willing sponsors and get your package reviewed if you maintain your package in a team. I wouldn't mind having this in pkg-gnome. That way you could get somebody from the team to sponsor uploads, plus you could help with the other C++ bindings ;) But this is up to you, you can keep the package in collab-maint. BTW if you haven't found a sponsor yet I'll be happy to take a look at it. Just let me know. Cheers, Emilio -- To UNSUBSCRIBE, email to debian-gtk-gnome-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/537c5a64.3000...@debian.org
Re: Status of GNOME 3.10 in Debian?
On 04/04/14 14:16, Johannes Rohr wrote: One question: On https://plus.google.com/u/0/+WorldofgnomeOrg/posts/WunFLk5ES6W I read in a comment: The new decision is: all Gnome versions released close to Debian freeze will come to Debian sid and testing, the other versions stay on experimental (like 3.10). Is this accurate? Personally, I like being up to date, but using experimental has been a constant PITA, because of frequent dependency issues. I don't really understand what that comment is saying. What is really happening is that we're working on updating GNOME to 3.12. Some stuff is in unstable and testing already, but a few (important) packages are only available in experimental right now. That is because we need to do transitions because of library ABI changes and SONAME bumps, but we're working on those and we should have all of 3.12 in testing/unstable this month. Regards, Emilio -- To UNSUBSCRIBE, email to debian-gtk-gnome-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/533f3c61.6010...@gmail.com
Re: Status of GNOME 3.10 in Debian?
On 20/03/14 08:16, Johannes Rohr wrote: Am 24.01.2014 09:27, schrieb Jordi Mallach: El dj 23 de 01 de 2014 a les 13:44 +0100, en/na Johannes Rohr va I'd really love to test out GNOME 3.10, but in the current incomplete state it seems to make limited sense. Just curious to know... I suspect things will start moving when #727708 is closed. at https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=727708 it says: This issue was decided by committee vote concluded 11 Feb 2014: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=727708#6734; So what is holding things up? Meanwhile, some GNOME 3.12 beta packages seem to have been uploaded. Isn't that a bit too messy? I mean - mixing three different GNOME releases in the archive? A bit, yes. We plan on pushing 3.12 to sid as soon as 3.12 final is released. That is, next week. That will take a while to complete as there are various transitions involved, but we'll get there. Emilio -- To UNSUBSCRIBE, email to debian-gtk-gnome-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/532ab3a7.4090...@debian.org
Re: Cinnamon 2.x
On 01/02/14 18:01, Roelof Wobben wrote: Hello, Does anyone know if someone is working on this. If not, can I work on this when I ready for it. I just begin my training for maintainerschip. We don't know, this list is not related to cinnamon. Ask its maintainers. Emilio -- To UNSUBSCRIBE, email to debian-gtk-gnome-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/52ed2fdc.9090...@debian.org
Re: GNOME 3.8 in unstable?
On 11/09/13 11:31, Jean-Christophe Dubacq wrote: Le 08/09/2013 10:47, Osamu Aoki a écrit : Or is there any principal reason not to update the remaining portions of the GNOME desktop in Debian? I tried ; this is currently very difficult, because systemd is quite intricated with gnome-shell. Switching everything at the same time (a new xserver-xorg-core was installed, but without any video driver) broke all of my system. Anyway, with classic init in place, GNOME 3.8 seems to be working fine here. Right now, it is uninstallable, and I can't manage to get apt to tell me why: root# LC_ALL=C apt-get install -t experimental gnome-shell empathy nautilus evolution gnome-contacts Reading package lists... Done Building dependency tree Reading state information... Done The following extra packages will be installed: cheese cheese-common empathy-common evolution-common evolution-data-server evolution-data-server-common evolution-plugins folks-common gdm3 gir1.2-gdm3 gir1.2-gnomedesktop-3.0 gir1.2-ibus-1.0 gir1.2-mutter-3.0 gir1.2-telepathylogger-0.2 gnome-control-center gnome-control-center-data gnome-session gnome-session-bin gnome-session-common gnome-settings-daemon gnome-shell-common gnome-shell-extensions gnome-tweak-tool gsettings-desktop-schemas gstreamer1.0-nice libcamel-1.2-43 libcheese-gtk23 libcheese7 libcrack2 libebackend-1.2-6 libebook-1.2-14 libebook-contacts-1.2-0 libecal-1.2-15 libedata-book-1.2-17 libedata-cal-1.2-20 libedataserver-1.2-17 libevolution libfarstream-0.2-2 libfolks-eds25 libfolks-telepathy25 libfolks25 libgdm1 libgnome-desktop-3-7 libgtkhtml-4.0-0 libgtkhtml-4.0-common libgtkhtml-editor-4.0-0 libgweather-3-3 libgweather-common libibus-1.0-5 libmutter0b libpam-systemd libpwquality-common libpwquality1 libsystemd-daemon0 libsystemd-journal0 libtelepathy-farstream3 libtelepathy-logger3 libudev1 libwacom-common libwacom2 libytnef0 libzeitgeist-1.0-1 mutter-common nautilus-data nautilus-sendto nautilus-sendto-empathy systemd Suggested packages: evolution-exchange evolution-plugins-experimental evolution-data-server-dbg pidgin gajim systemd-ui Recommended packages: ntp system-config-printer cracklib-runtime The following packages will be REMOVED: gnome gnome-applets gnome-core gnome-panel gnome-screensaver gnome-session-fallback libcheese-gtk21 libcheese3 libebook-1.2-13 libedata-book-1.2-13 libedataserverui-3.0-1 libmutter0 The following NEW packages will be installed: gir1.2-gdm3 gir1.2-ibus-1.0 gstreamer1.0-nice libcamel-1.2-43 libcheese-gtk23 libcheese7 libcrack2 libebackend-1.2-6 libebook-1.2-14 libebook-contacts-1.2-0 libecal-1.2-15 libedata-book-1.2-17 libedata-cal-1.2-20 libedataserver-1.2-17 libfarstream-0.2-2 libgdm1 libgnome-desktop-3-7 libgweather-3-3 libibus-1.0-5 libmutter0b libpam-systemd libpwquality-common libpwquality1 libsystemd-daemon0 libsystemd-journal0 libtelepathy-farstream3 libtelepathy-logger3 libudev1 libytnef0 libzeitgeist-1.0-1 systemd The following packages will be upgraded: cheese cheese-common empathy empathy-common evolution evolution-common evolution-data-server evolution-data-server-common evolution-plugins folks-common gdm3 gir1.2-gnomedesktop-3.0 gir1.2-mutter-3.0 gir1.2-telepathylogger-0.2 gnome-contacts gnome-control-center gnome-control-center-data gnome-session gnome-session-bin gnome-session-common gnome-settings-daemon gnome-shell gnome-shell-common gnome-shell-extensions gnome-tweak-tool gsettings-desktop-schemas libevolution libfolks-eds25 libfolks-telepathy25 libfolks25 libgtkhtml-4.0-0 libgtkhtml-4.0-common libgtkhtml-editor-4.0-0 libgweather-common libwacom-common libwacom2 mutter-common nautilus nautilus-data nautilus-sendto nautilus-sendto-empathy 41 upgraded, 31 newly installed, 12 to remove and 461 not upgraded. Need to get 18.3 MB/64.6 MB of archives. After this operation, 13.9 MB of additional disk space will be used. Do you want to continue [Y/n]? n Abort. I sincerely would like some means of testing this new gnome-shell, but right now its dependencies are too entangled in experimental mess. Maybe it's only an updated gnome-core or gnome package that is missing in experimental. Well that was installing gnome-shell and friends and removing gnome-panel and friends, which seems sensible to me. If you want gnome-panel et al, try to install them afterwards, but they may need rebuilds for the stuff that is in experimental (most notably evolution-data-server 3.8) which we haven't done, so it's very likely that you can't have gnome-panel together with gnome-shell 3.8 just yet. Emilio -- To UNSUBSCRIBE, email to debian-gtk-gnome-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/52303a70.1010...@debian.org
Re: GNOME 3.8 in unstable?
On 11/09/13 12:41, Johannes Rohr wrote: And I really don't get what is still holding up GNOME 3.8. Right now it's the evolution-data-server transition, which is being worked on. After that happens, it'll probably be time to get mutter, gnome-shell, g-s-d, g-c-c and so into unstable, bringing the last few bits of G3.8 there. And then, we can start getting 3.10 in, hopefully much faster this time. Emilio -- To UNSUBSCRIBE, email to debian-gtk-gnome-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/52304cae.8040...@debian.org
Re: Meta-gnome3 dependency on xul-ext-adblock-plus (Bug #689858)
On 18/06/13 11:55, Johannes Rohr wrote: Am Dienstag, den 18.06.2013, 11:08 +0200 schrieb Jordi Mallach: El dt 18 de 06 de 2013 a les 08:50 +0200, en/na Johannes Rohr va escriure: Now, maybe there is a good reason to include this package into the GNOME desktop metapackage, but if there is one, I'd like to know what it is. What is the rationale behind this decision? How do you define what is part of GNOME and what isn't? meta-gnome3 (1:3.4+3) unstable; urgency=low [...] * Install iceweasel instead of epiphany :( See bug#682481. * Let gnome recommend iceweasel-l10n-all. * Require firefox extensions that match epiphany functionality: keyring, adblock. Thanks for filling me in! At the same time, there seem to be no open security related RC bugs file against epiphany in Debian at this time: http://bugs.debian.org/cgi-bin/pkgreport.cgi?src=epiphany-browser;tag=security The problem is rather with webkit in general and/or webkitgtk+ in particular. Emilio -- To UNSUBSCRIBE, email to debian-gtk-gnome-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/51c041b9.8030...@debian.org
Re: Meta-gnome3 dependency on xul-ext-adblock-plus (Bug #689858)
On 04/06/13 11:29, Johannes Rohr wrote: while I do use adblock plus with Iceweasel, it seems a bit arbitrary to me that the gnome meta package declares a dependency on it. Adblock plus is not part of the GNOME desktop. In addition, it pulls in iceweasel which also isn't. What is the rationale behind this decision? Until now, I had assumed, that the policy regarding Debian's GNOME desktop was to closely reflect the official GNOME desktop as defined by upstream. I see that the gnome metapackage is not totally strict on that, but still, most packages which are not part of the official GNOME release are suggests or recommends, not depends. Why this exception, for a package which isn't even based on the GNOME platform? IIRC, The GNOME web browser is epiphany. However the GNOME task (which we don't maintain) doesn't install that in a default install, but installs iceweasel instead. Therefore we switched the metapackage to match that and added adblock because that's some important functionality that epiphany has by default. Emilio -- To UNSUBSCRIBE, email to debian-gtk-gnome-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/51adb618.7070...@debian.org
Re: GNOME 3.8 in unstable?
On 17/05/13 08:13, Johannes Rohr wrote: Dear maintainers, sorry for my impatience! I noticed that GNOME 3.8 is still in experimental, even though the Wheezy release process is over. Are there any indications as to when it is going to make it into unstable? Is it waiting for some transition to complete first? Yes, we're basically waiting for unstable to cool down (too many transitions atm). Emilio -- To UNSUBSCRIBE, email to debian-gtk-gnome-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/5195f33e.1060...@debian.org
Testing gdm3 3.4.1-7
Hi all, gdm3 3.4.1-7 from unstable fixes an important accessibility issue (the screen reader no longer working on gdm). To make sure the packages are fine, I'd appreciate if people could test it (you'll also need gnome-session 3.4.2.1-4). After installing those, make sure gdm still works as expected. Also make sure to test the Screen Reader checkbox in the top panel, inside the accessibility menu there. Enabling Screen Reader should start orca and it should read your screen. If we have confirmation that the packages are working fine, we may be able to ship this in wheezy r0. Otherwise it'll be delayed to the first point release (r1). Thanks, Emilio -- To UNSUBSCRIBE, email to debian-gtk-gnome-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/516beb47.4000...@debian.org
Re: Gnome Screensaver (experimental) not working?
On 03/03/13 16:08, Arief M Utama wrote: On Sun, Mar 3, 2013 at 5:47 PM, Emilio Pozuelo Monfort po...@debian.orgwrote: It could be the new gsettings-desktop-schemas 3.7.90, do you have that installed? Yes! Does downgrading it to 3.6 fix the problem? and... yes! Thanks a bunch Emilio! Great. The next gsettings-desktop-schemas will have a breaks on the shell so people don't upgrade one without the other. ps: do you happen to know what's going on with gnome-keyring as well? (why is it failing to unlock login keyring on login) No idea. Unless you have set gdm to autologin, in which case that's normal because it doesn't get the password. Or unless your keyring password and your user password are different (they need to be the same for that to work). Emilio -- To UNSUBSCRIBE, email to debian-gtk-gnome-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/51349932.50...@debian.org
Re: Gnome Screensaver (experimental) not working?
On 03/03/13 09:18, Arief M Utama wrote: Just realized yesterday that my nice, stylish screen-lock (gdm-shell enabled) is not working anymore. Tried some things, and downgraded libc6 and dbus back to unstable version also... still not working. It could be the new gsettings-desktop-schemas 3.7.90, do you have that installed? Does downgrading it to 3.6 fix the problem? Emilio -- To UNSUBSCRIBE, email to debian-gtk-gnome-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/51332a3b.5000...@debian.org
Re: Analysis of the gnome3 transitions
On 15/04/11 11:17, Josselin Mouette wrote: 1. libnotify This has been requested and is tracked as #622363. As mentioned in the bugreport, we will try to get Xfce before (asked earlier and seems to simplify the transition a bit). Yes, although libnotify 0.6 doesn’t require anything and would help some reverse dependencies already. Bigon said 0.6 doesn't link against any gtk+ version though it still uses it. That's buggy (it should link against the version it was built against) and will cause various kind of bugs, so I think we should go for 0.7 directly. If the number of rdeps is too big we can rename the -dev package. 3. devhelp and, anjuta-extras I guess. If everything needed is already ready in sid/wheezy, you can go ahead with this. The one thing I’m wondering about starting to upload GTK3 applications is the lack of a good theme. The only theme available currently is Adwaita; we could upload it to unstable but this means changing the default theme. We'll change it sooner or later, so this shouldn't be a big issue. Or am I missing something? 4. gnome-keyring It is almost a self-contained transition (gnome-keyring + seahorse). However it needs to be done early because empathy (involved in other transitions) will need it. This semi-started :/ libgnome-keyring 3.0 has been uploaded and triggered some bad side effects (#622556). It might be a good idea to do this one, if we can avoid updating seahorse-plugins ; or revert the upload. Yeah, I think upstream f*cked up this one too. I’ll see how this can be fixed. This is being worked on. gnome-keyring and seahorse are on NEW. almanah should be uploaded soon, and seahorse-plugins will need to be removed from testing (the plugins have either not being ported, or need G3 packages that are only on experimental, e.g. nautilus 3 for the nautilus extension). It will come back at some point after the other transitions. Should be pretty self-contained, so hopefully won't cause any big issues. 5. gedit This probably means not before gnome-keyring and devhelp transitions are over, I guess. In any case, if we do one transition before the other, the gedit plugin will stop working for a while. I think it’s a necessary evil, otherwise we’re going to entangle all these transitions together. Agreed. Cheers, Emilio -- To UNSUBSCRIBE, email to debian-gtk-gnome-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4da818f7.3010...@debian.org
Re: gnome 3 minimize button (etc)
On 08/03/11 01:52, Miles Bader wrote: hob...@poukram.net (Rémi Letot) writes: They didn't go insane, thanks. Thats a matter of opinion. They just changed the default way to do it, and they didn't remove the possibility to revert the change. And having used it for a few days, I must say it's quite convincing. What's convincing? I mean, maximize isn't too much of an issue -- double-clicking on the title bar seems reasonably convenient and intuitive -- but making minimize inconvenient _is_ an issue, especially since there doesn't seem to be a good reason for doing so. There is. There's no easy/intuitive way of bringing minimized windows back since there's no task bar like in GNOME 2 (yes, you can do it with alt+tab, but most non-power users don't know that). You can still do it yourself with alt+f9. Emilio -- To UNSUBSCRIBE, email to debian-gtk-gnome-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4d7610ea.6080...@debian.org
Re: GNOME 3 and panel applets
On 14/02/11 20:46, brian m. carlson wrote: On Mon, Feb 14, 2011 at 06:17:36PM +0100, Josselin Mouette wrote: The panel remains, but it will be a GTK3 / D-Bus panel. In its current state, it doesn’t support the good old GTK2 / bonobo applets, of which we have a lot in the archive. Upstream confirmed they don’t have time to support them for 3.0 unless someone steps up to do the job. Will the existing GNOME 2 gnome-applets be ported to GNOME 3? After all, they are part of GNOME. They're also not listed in your dd-list. They have already been ported upstream. Cheers, Emilio -- To UNSUBSCRIBE, email to debian-gtk-gnome-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4d5a4850.2060...@gmail.com
Re: GNOME 3 and panel applets
On 15/02/11 09:15, Michael Biebl wrote: That said, the upstream unstable branch of tracker apparently has a port of tracker-search-bar using libpanelapplet-3.0, which I assume is the new D-Bus based panel in GNOME 3.0. I can't seem to find such a package in Debian just yet. Joss, when do you plan that this will be available in unstable or experimental? It could go into experimental as soon as somebody packages gnome-panel 2.91.x. Cheers, Emilio -- To UNSUBSCRIBE, email to debian-gtk-gnome-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4d5a4e34.4000...@debian.org
Re: GNOME 3 and panel applets
On 14/02/11 17:36, Joachim Breitner wrote: Also, for link-monitor-applet, I need to find out whether gob2 needs to be updated. But it seems that GTK-3 still uses GLib-2, so this might work. There's no GLib 3. Emilio -- To UNSUBSCRIBE, email to debian-gtk-gnome-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4d596bd3.6040...@debian.org
Re: Order names for gnome applets
On 09/08/10 17:04, Roman V. Nikolaev wrote: We have trend to order applet names. For example: xul-ext-... opensync-plugin-... cairo-dock-... etc. Have a plan to make order for gnome panel names? Not at the moment. You can name it however you want. Regards, Emilio -- To UNSUBSCRIBE, email to debian-gtk-gnome-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4c604243.3010...@debian.org
Re: GNOME 2.32 plans
Hi, On 04/08/10 10:24, Josselin Mouette wrote: as some of you might have heard, there is going to be a GNOME 2.32 release in September, GNOME 3.0 being delayed to next spring. For a large number of modules, 2.32 is going to be a pure bugfix release based on 2.30. Therefore I propose the following approach: * For bugfix releases, we upload them to unstable and try to put them in squeeze. This sounds a little error-prone, but I don't have a better idea than let's just release with 2.30, so I'm fine with it. (If we upload something that shouldn't have been uploaded, we can always reupload the 2.30 package). * For modules requiring GSettings, we keep the 2.30 version, maybe with some backported bugfixes. GSettings is simply too fresh, we don’t have enough hindsight and we don’t want to have to direct users through 2 different configuration mechanisms. Agreed. * For modules not requiring GSettings but requiring other new features in Glib or GTK+ 2.x, see later. I doubt we will have many such modules. Then there’s the case of Glib. Glib 2.26 will be backwards compatible, but the introduction of GSettings causes some packaging changes. I’m not too fond of risking to break reverse dependencies. Having this version in squeeze will depend on the calendar, but I’m not too fond of risking to break thousands of reverse dependencies. I guess we’ll have to see how the freeze is coming when it’s out. What packaging changes are you afraid of? The new triggers and the new -bin package? What problems could they cause to reverse dependencies? Are there packages calling gio-querymodules themselves? For GTK+ 2.22, things are in a similar state. Even larger packaging changes are being introduced because gdk-pixbuf was split in a separate module. However I’d prefer to see it in squeeze, otherwise backporting GTK+ 3.0 will be very hard. Of course I’m only proposing it since it doesn’t use GSettings. For GTK+ 3.0, the plan is to rely on backports since we don’t even have a release date. I've heard about the release being on Christmas, but that's probably not set in stone yet. If we ever happen to see it available during early freeze time, we can try to squeeze it in. But in any case, direct or indirect dependencies of meta-gnome2 must not depend on it. It would be just so that GTK+ 3 applications can be built on squeeze without backports. Do you think this is realistic? I'd say it depends on when the RT plans to freeze the archive. If soon (e.g. this month) maybe we should just release with 2.30? But if they don't plan to release anytime soon, updating GLib and GTK+ doesn't bad to me, although I don't see much benefits in updating GLib. Cheers, Emilio -- To UNSUBSCRIBE, email to debian-gtk-gnome-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4c598567.2050...@debian.org
Re: GNOME 2.32 plans
On 04/08/10 18:14, Josselin Mouette wrote: Le mercredi 04 août 2010 à 17:21 +0200, Emilio Pozuelo Monfort a écrit : I'd say it depends on when the RT plans to freeze the archive. If soon (e.g. this month) maybe we should just release with 2.30? But if they don't plan to release anytime soon, updating GLib and GTK+ doesn't bad to me, although I don't see much benefits in updating GLib. The benefit of updating Glib is to be able to upload GTK+ 2.22 - which in turn is necessary if we want GTK+ 3.0 backports to work. Oh right. It's probably that GTK+ 3.0 will depend on GLib 2.28, and maybe a new libgdk-pixbuf, although it would be easier to upload a newer libgdk-pixbuf to backports if the split is already in stable. I'm fine with updating them. Is there an approximated freeze date? Regards, Emilio -- To UNSUBSCRIBE, email to debian-gtk-gnome-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4c5995ae.6070...@debian.org
Re: plans for bluefish 2.0
On 18/05/10 21:32, Ali wrote: Hi Debian gnome developers, do you have any plans for bluefish 2.0? We don't maintain it. But see this: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=570731 Cheers, Emilio -- To UNSUBSCRIBE, email to debian-gtk-gnome-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4bf2f061.20...@debian.org
Re: How to add a new SW package to the Debian distribution?
On 04/03/10 21:17, Luis Felipe wrote: thanks for the quick answer! I have decided to sent an ITP for being the package maintainer too. Good. You can mail debian-mentors@ when you need sponsorship, or if you have questions. Cheers, Emilio -- To UNSUBSCRIBE, email to debian-gtk-gnome-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4b90192f.7030...@debian.org
Re: How to add a new SW package to the Debian distribution?
Hi, On 03/03/10 23:18, Luis Felipe wrote: Hi all, I would like to know how to add a new SW package to the Debian distribution. This package is named Usbview2 and is hosted under SourceForge.net (see [1]). I have developed this application and I would like to share over Debian too. Can you please provide me some infos about this topic? Thanks in advance. You basically need to report an RFP (request for package) report if you want someone to package it in Debian and maintain it, or an ITP (intent to package) if you want to maintain it yourself in Debian. Have a look at http://www.debian.org/devel/wnpp/ Cheers, Emilio -- To UNSUBSCRIBE, email to debian-gtk-gnome-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4b8ee7e4.2050...@debian.org
Re: Bug triage week-end
Heya, Josselin Mouette wrote: some time ago, someone (was it HE?) proposed to reserve a week-end during we would try to close, forward and fix as many as possible of the bugs reported on the team-maintained packages. Julien Cristau proposed to organize focused BSPs on November. It didn’t turn into reality until now, but I’d like to bring back the idea. It would be very welcome to reduce the number of bugs, and it would be a perfect time for newcomers to learn about GNOME packages. Cool! Would you people be available for an upcoming week-end during February? I should as long as it's not the first one. Cheers, Emilio -- To UNSUBSCRIBE, email to debian-gtk-gnome-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: How to break circular Build-Depends between gir-repository and gstreamer?
Daniel Schepler wrote: On Saturday 28 November 2009 04:08:01 Josselin Mouette wrote: As for Tracker, you’d have to explain how this indirect dependency happens. Through nautilus (for libnautilus-extension-dev), which Build-Depends on libtrackerclient-dev. Good catch, I've reported it at https://bugzilla.gnome.org/show_bug.cgi?id=603421 Cheers, Emilio signature.asc Description: OpenPGP digital signature
Re: [fwd] RFC: organising focused BSPs
Hi Julien, Julien Cristau wrote: I've sent the attached mail to debian-qa, and would be interested to have the opinion of maintainers of other big (sets of) packages. [ mail about focused BSPs ] I think that's a great idea! If they were done I'd try to participate, and if done in GNOME packages I'd help organizing / giving guidance to people. We could do it once a month, each one for a different set of packages. How does it sound? Cheers, Emilio signature.asc Description: OpenPGP digital signature
Re: Patch for glabels package
Rodolphe Pelloux-Prayer wrote: Le samedi 20 juin 2009 à 22:31 +0200, Emilio Pozuelo Monfort a écrit : Rodolphe Pelloux-Prayer escribió: Le jeudi 18 juin 2009 à 00:10 +0200, Emilio Pozuelo Monfort a écrit : Can you update the patch? Yep, voila! I've seen that lintian raise new warnings but I didn't take time to fix them (actually, I need to read about and make tests). Thanks, applied! I've fixed a couple of lintian warnings, and merged your changelog with the previous one (which also was UNRELEASED). The build-dependencies still need some changes (that were missing in the past), e.g. GLib. I updated the build-dependencies but I don't know how to correct the warnings (I'm definitly not a libtool/gcc/autotools expert :) ) Thanks, applied! Best regards, Emilio signature.asc Description: OpenPGP digital signature
Re: gnome-cups-manager replacement
Adam C Powell IV wrote: Greetings, Was just trying to install an old gnome-cups-manager, but it not only needs a rebuild (and forward-port to g++ 4.3+), but also *conflicts* with the lenny gnome meta-package! What new package provides similar functionality? Are there any plans for something like it in unstable? Have a look at system-config-printer, I think it's the successor. Emilio signature.asc Description: OpenPGP digital signature
Re: Patch for glabels package
Rodolphe Pelloux-Prayer escribió: Le jeudi 18 juin 2009 à 00:10 +0200, Emilio Pozuelo Monfort a écrit : Can you update the patch? Yep, voila! I've seen that lintian raise new warnings but I didn't take time to fix them (actually, I need to read about and make tests). Thanks, applied! I've fixed a couple of lintian warnings, and merged your changelog with the previous one (which also was UNRELEASED). The build-dependencies still need some changes (that were missing in the past), e.g. GLib. Cheers, Emilio signature.asc Description: OpenPGP digital signature
Re: Patch for glabels package
Rodolphe Pelloux-Prayer escribió: Oops, i've tried to check everything but i forget the patch itself :) This patch should be better. Seems better, yeah :) Just one comment: you should comment all your changes in debian/changelog, e.g. - New upstream version. + Fixes foo. Closes: #123. + Bar now works correctly. Closes: #1234. - debian/patches/foo: removed, applied upstream. - debian/patches/baz: likewise. - Standards-Version is 3.8.2, no changes needed (or list the changes) - Added Vcs-Browser and Vcs-Svn fields. etc. Can you update the patch? Cheers, Emilio signature.asc Description: OpenPGP digital signature
Re: Patch for glabels package
Rodolphe Pelloux-Prayer escribió: Hi, Attached a small patch for the package of the latest upstream release of glabels (2.2.5). Hi Rodolphe, The patch is not against our svn, it seems you diffed against your previous changes or something like that. Cheers, Emilio signature.asc Description: OpenPGP digital signature
Re: Splitting of the gnome-python* source packages - MBF
Hi Joss, Josselin Mouette wrote: 1. GNOME-PYTHON I propose to file wishlist bugs on the packages that can move to using python-gconf. 2. GNOME-PYTHON-DESKTOP I propose to file important bugs on all packages depending on python-gnome2-desktop, making them RC once the package is removed (not until at least a few months, though). 3. GNOME-PYTHON-EXTRAS Bugs have already been filed for egg.trayicon, gtkhtml2 and gtkmozembed. I propose to complete them with gtkspell bugs and to make them important. They would become serious before the squeeze release. All sound good to me. Cheers, Emilio signature.asc Description: OpenPGP digital signature
