I'd be happy to help. I can do the 29th.
On Fri, Mar 10, 2017 at 3:07 PM, Steve Langasek
wrote:
> On Fri, Mar 10, 2017 at 02:02:28PM -0500, Jeremy Bicha wrote:
> > On Fri, Mar 10, 2017 at 1:47 PM, Robie Basak
> wrote:
> > > Since it is after feature freeze, I propose that anything in the queue
Hello, Stef!
I'm the maintainer of the current backup software pre-installed in Ubuntu
(deja-dup).
That menu item is installed by deja-dup via a nautilus extension. Feel
free to copy that code and use it for your own software (it's GPL and
small).
As for a generic integration API, I feel like t
On Tue, Oct 14, 2014 at 2:53 PM, Steve Langasek
wrote:
> I don't know whether the MIR team wants to grant a
> variance for this library as a result.
>
It isn't a MIR requirement that a symbols file be present. Just a wishlist
item as part of best packaging practices.
-mt
--
ubuntu-devel maili
Another option would be to call "dh_makeshlibs -V" with no version
argument. This is a conservative option, so the reverse depends will be
tightly coupled. But it's safe.
On Fri, Oct 10, 2014 at 9:57 AM, Bjoern Michaelsen <
bjoern.michael...@canonical.com> wrote:
> Hi,
>
> so liborcus now build
On Fri, Mar 21, 2014 at 10:08 AM, Alexander Sack wrote:
> On the front of data, we haven't seen much new. For instance we only
> know about a single case where this "all halt" event has negative
> impact; so please speak up if you are affected.
>
I'm trying to shepherd through the big split gree
On 04/09/12 10:29, Michael Hall wrote:
It's possible for me to upload a package to Universe in Precise's
development phase, then for an unrelated package by the same name to be
in Debian's archives when we do the Quantal sync.
How is this currently handled?
I believe badly. But it's not been
On 04/09/12 10:12, Emmet Hikory wrote:
Michael Terry wrote:
I imagine the easiest way to avoid this is to namespace the package
names too.
(Though with namespaced packages, the user can end up in a weird
situation if the Extras package "foo" does find its way into Debian
and Ubun
On 04/09/12 08:51, Michael Hall wrote:
If the app is added to Ubuntu proper (directly or from Debian) for a
development release after it is already in Extras for a stable
release, the Extras package will not be forward-copied to the
development release and the developer will not be able to upload
On 19/07/12 15:54, Barry Warsaw wrote:
If there are no objections in the next day or so, I'll do the sync. Note that
we're already in sync with claws-mail-extra-plugins.
I was involved in pushing that fix. I still think it's a good patch.
But I don't have strong feelings about whether it's
On 16/04/12 02:03, Steve Langasek wrote:
And regardless of which we decide to use as the default, both of amd64 and
i386 will continue to be supported architectures for the length of 12.04 LTS
and will remain available for download.
There seems to be an unstated assumption that the default reco
Hello! The just-released Unity Greeter 0.2.4 now uses little badge
icons to represent sessions (like kde/xfce/unity, etc).
A badge is shown to indicate which session is default for a user and
each session's badge is shown when choosing a new default.
0.2.4 only ships kde, gnome, and unity ba
On 07/21/2011 09:39 PM, Kyle Nitzsche wrote:
Documentation [1] says to simply bzr push to trunk tip: 'bzr push
lp:ubuntu/tomboy'. Can*anyone* push to ubuntu trunks? If I don't have the
required privilege, what would I do after my merge proposal is approved? I
thought maybe (as with the uni
Hello! I was just considering how a dh_python2 transition for the
various ubuntuone python modules would work. They all install into the
ubuntuone module, so would need to be updated at the same time.
Is there a recommended way to avoid the problem of users partially
upgrading (either from b
On 02/04/11 09:56, Scott Ritchie wrote:
This has long been "good practice" for a variety of reasons
I agree with all your reasons, but tend to prefer ~lucid1, ~maverick1,
etc. in case the same package is available for multiple releases.
-mt
--
ubuntu-devel mailing list
ubuntu-devel@lists.ubu
Hello, gentle developers!
Recently, Debian changed their gir policy to have package names more
accurately reflect the abi of the gir. Basically, gir1.0 became gir1.2.
The Desktop team has been making the transition this past week, and
we're largely done. All the core GNOME libraries have been c
15 matches
Mail list logo