Re: Fwd: Call for votes: Developer Membership Board restaffing

[Micah Gersten]

Let's try again with text...

On February 19, 2020 7:34:27 AM CST, Dan Streetman 
 wrote:

>
>On Fri, Feb 14, 2020 at 9:38 AM Robie Basak 
>wrote:
>>
>> The Developer Membership Board (DMB) has started a restaffing vote
>for
>> the seven members whose terms are expiring. The DMB is responsible
>for
>> reviewing and approving new Ubuntu developers. It evaluates
>prospective
>> Ubuntu developers and decides when to entrust them with developer
>> privileges. There are eight candidates:
>>
>> Łukasz Zemczak (sil2100)
>> Dan Streetman (ddstreet)
>> Simon Quigley (tsimonq2)
>> Thomas Ward (teward)
>> Eric Desrochers (slashd)
>> Micah Gersten (micahg)
>
>Hello @micahg, and thank you for your service on the DMB for all these
>years (since 2011)!
>
>However, I can't help but take note that even though you are a DMB
>member, you did not attend a single DMB meeting in 2019.  Since quorum
>has been a serious problem for the DMB, could you please provide some
>insight about why you want to remain on the board, and what your
>thoughts are about improving meeting attendance in the future?
>
>Thanks!

I originally wasn't going to remain on the board for this reason since I've had 
schedule conflicts.  However, I would like to try to ensure that there is a 
functioning board, so I submitted my name to insure there was a vote.  I 
remember showing up for at least one meeting at the end of the year with no 
quorum or agenda.  In that case there was no meeting and no roll call.
Anyways, I do intend to try to make at least one meeting per month.

Thanks,
Micah

-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: Does the backporters team need help?

[Micah Gersten]

On April 24, 2017 5:51:02 PM CDT, Mattia Rizzolo  wrote:
>On Mon, Apr 24, 2017 at 06:44:29PM -0400, Scott Kitterman wrote:
>> The answer is clearly yes.  I've attempted a few times to pass off
>backports
>> to someone new and apparently failed.  I'll be glad spend a few
>minutes
>> getting you up to speed, but as I'm not involved in Ubuntu
>development
>> anymore, I don't really have time for more than that.
>
>I also wanted to join the team, and I had a few words with Scott about
>that, but then failed at arranging the few minutes he is talking about…
>
>Anyhow, I'm interested in the position just because I'm interested in
>backports, but if somebody was to take care of approving the uploads,
>etc, I'm more than happy to retract my proposition :)

Yes, indeed, the team could use assistance.  I was on vacation and am catching 
up on things.  I would be happy to start getting more people involved starting 
next week.

Thanks,
Micah

-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: Patch pilot report: 2015-08-03

[Micah Gersten]

On August 3, 2015 8:42:05 AM CDT, Daniel Holbach  
wrote:
>Hello everybody,
>
>NOTE: please help out with sponsoring, we have quite a number of
>request
>piled up!
>
>   http://reqorts.qa.ubuntu.com/reports/sponsoring/
>
>Here's what I got done in my shift today:
>
>
>
>syncpackage -s logan -b 1480750 libxaw -f
>syncpackage -s ari-tczew -b 1480612 libpciaccess -f
>syncpackage -s ari-tczew -b 1480500 libxrandr -f
>syncpackage -s ari-tczew -b 1480488 jbig2dec -f
>syncpackage -s ari-tczew -b 1478718 libfontenc -f
>syncpackage -s ari-tczew -b 1478720 python-ipaddress -f
>syncpackage -s ari-tczew -b 1478719 python-cryptography-vectors -f
>Sync wmsysmon 0.7.7-8 (universe) from Debian unstable (main)
>(pad.lv/1475495)
>Sync wmtop 0.84-10 (universe) from Debian unstable (main)
>(pad.lv/1475494)
> - synced.
>
>Merge 0.3.0-4 from debian experimental (pad.lv/1479156)
>lp:~noskcaj/gnome-menus/3.13.3
>lp:~noskcaj/ubuntu/wily/gdm/3.16.2
> - uploaded.
>
>Please merge antlr3 3.2-11 (universe) from Debian unstable (main)
>(pad.lv/1474294)
>Sync trafficserver 5.3.0-2 (universe) from Debian unstable (main)
>(pad.lv/1476470)
> - pinged.
>
>lp:~noskcaj/gnome-user-share/3.8
>lp:~noskcaj/ubuntu/wily/light-locker
> - commented with a few questions.
>
>
>Have a great day,
> Daniel

Please also keep in mind that we're in the middle of the libstdc++ transition 
[1] and the subsequent transitions when sponsoring.

Thanks,
Micah
[1] https://wiki.ubuntu.com/GCC5

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: [ubuntu/wily-proposed] libxcb 1.11-0ubuntu1 (Accepted)

[Micah Gersten]

>From: Robert Ancell 
>Date: 10:09pm, Tue, Jul 14, 2015
>Subject: [ubuntu/wily-proposed] libxcb 1.11-0ubuntu1 (Accepted)
>To: 
>
>
>libxcb (1.11-0ubuntu1) wily; urgency=medium
>
>  * New upstream release (LP: #1402966)
>  * debian/control:
>- Add build-depends on xutils-dev
>- Bump build-depends on xcb-proto
>  * debian/libxcb-xprint0.symbols:
>- Add new symbols
>  * debian/libxcb-xkb1.symbols:
>- Some symbols removed, but no dependencies use them
>  * debian/rules:
>- Bump shlibs

Were the symbols removed not supposed to be part of the public interface 
(current assumption) or did upstream not bump SONAME appropriately?   If the 
symbols were supposed to be public but removed, that could still adversely 
affect locally built software.
Thanks,
Micah
-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Next Developer Membership Board (DMB) Meeting is June 8

[Micah Gersten]

Due to the Memorial Day holiday in the US, we've canceled the Developer
Membership Board meeting scheduled for May 25.  The next meeting will be
Monday June 8th, 2015 at 15:00 UTC.

Thanks,
Micah Gersten
on behalf of the DMB

-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: More sponsors needed

[Micah Gersten]

On 02/26/2014 02:27 AM, Jackson Doak wrote:
> Hello everyone,
>
> Can some more people please work on reducing the sponsoring queue?
> It's got 60+ requests now, many of which are important bugfixes or
> release critical to different
> flavours. http://reqorts.qa.ubuntu.com/reports/sponsoring/

We're in Beta Freeze [1] right now, so unless it's critical to the
milestone, or not seeded, it needs to wait until after the freeze is
lifted anyways.

Thanks,
Micah

[1] https://wiki.ubuntu.com/TrustyTahr/ReleaseSchedule

-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: [ubuntu/saucy-proposed] i7z 0.27.2-2ubuntu1 (Accepted)

[Micah Gersten]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 08/15/2013 09:58 AM, Jackson Doak wrote:
> i7z (0.27.2-2ubuntu1) saucy; urgency=low
>
>   * Merge from debian unstable. Remaining changes:
> - debian/control: Future-proof by adding x32 to the architecture list
>
> Date: Thu, 15 Aug 2013 07:44:30 +1000
> Changed-By: Jackson Doak 
> Maintainer: Ubuntu Developers 
> Signed-By: Matthew Fischer 
> https://launchpad.net/ubuntu/saucy/+source/i7z/0.27.2-2ubuntu1
>

This could've just been a sync, the changes were in Debian.  Also,
please use -v with the old package version when uploading a merge.

Thanks,
Micah
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)

iEYEARECAAYFAlIM9JkACgkQTniv4aqX/VnOqQCdFdbC8QADjNk97+FcJ8ubL4Xg
wV0AnA7UMHJVR9UCfV6wzR8+G9eCPHwm
=r46S
-END PGP SIGNATURE-

-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: Review of current autopkgtest failures, bucket into teams

[Micah Gersten]

On 07/25/2013 05:19 PM, Steve Langasek wrote:
> Hi Martin,
>
> On Thu, Jul 25, 2013 at 01:34:40PM +0200, Martin Pitt wrote:
>> == foundations ==
>> saucy-adt-pandas (regression)
> It looks like Dmitry Shachnev has fixed this up already - thanks, Dmitry!
>
> Beyond that, this is a package in universe which I don't think Foundations
> should be responsible for fixing the test suite in.  I think either this
> should be owned by MOTU, like other aspects of universe are, or we should
> not run / not block on autopkgtests for unseeded packages.

I agree that foundations shouldn't be responsible, but I'd rather not
see us get in the mindset that quality in universe is not needed.  If we
can automate testing, let's display the failures like any other
failure.  If after review it's decided to not block on the failure, so
be it, but let's have this be the exception and not the rule.

Thanks,
Micah

-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

preinst-uses-dpkg-maintscript-helper-without-predepends lintian check

[Micah Gersten]

So, apparently, this was removed in lintian 2.5.11 since Debian
oldstable has a high enough dpkg (1.15.8.13), but lucid doesn't
(1.15.5.6ubuntu4.5).  Should we add this check back to lintian in Ubuntu
until lucid is EOL (we should be able to do this in Debian since there
are lintian profiles now, so no diff should be required).  I'd be happy
to write a patch if this is desired.

Thanks,
Micah

-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: [ubuntu/saucy-proposed] livecd-rootfs 2.154 (Accepted)

[Micah Gersten]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 07/04/2013 11:50 AM, Ricardo Salveti de Araujo wrote:
> livecd-rootfs (2.154) saucy; urgency=low
>
>   [ Sergio Schvezov ]
>   * Adding ppa:ubuntu-unity/next for Touch to obtain unity8 and Mir.
>   * Switching to using the maliit plugin provided by maliit-framework.
>
> Date: Thu, 04 Jul 2013 13:44:08 -0300
> Changed-By: Ricardo Salveti de Araujo 
> Maintainer: Ubuntu Developers 
> https://launchpad.net/ubuntu/saucy/+source/livecd-rootfs/2.154
>
We've generally not allowed building images from PPAs in the main
archive.   Why is this change needed in the archive version?

Thanks,
Micah
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)

iEYEARECAAYFAlHVtVIACgkQTniv4aqX/VlhEwCfem9p81ykPGvT2c3K8DI82NUe
EaYAnR9BE97wpVvuPHfUxgw6iXVq7Rsv
=0MR/
-END PGP SIGNATURE-


-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: indicator-weather broken, should we drop it from raring?

[Micah Gersten]

On 04/19/2013 01:25 PM, Barry Warsaw wrote:
> On Apr 19, 2013, at 06:36 PM, Sebastien Bacher wrote:
>
>> I guess you have a configured indicator with your location, right? ;-)
> I do!  But I fear I might forget my umbrella the next time I travel out of my
> home location. :)
>
>> The current bug makes impossible to configure it/add a location, so it's
>> basically useless as a new package to install (or you need to get the woeid
>> code and tweak the config by hand, but if you do that you can probably as
>> well get the package from a ppa or launchpad library).
>>
>> The users who have it installed can keep it, nothing is going to remove it
> >from your system because we drop it from the archive.
>
> That's a good point.  Given that as a fresh install, it's currently pretty
> useless, I suppose it makes sense to remove it.  OTOH, I don't like making
> this decision so close to the release.  Isn't there a chance that someone will
> be motivated to do an SRU to fix the most egregious problems later?
>
If it's totally broke, let's drop it and backport it if/when it gets
fixed.  A backport will appear in software center just like something in
the main archive if there's no archive version for it AIUI (apt
certainly treats it that way since backports are enabled by default, but
pinned lower).

Micah

-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Blueprint renaming doesn't notify subscribers (was: Re: Let's Discuss Interim Releases (and a Rolling Release))

[Micah Gersten]

On 02/28/2013 11:46 PM, Scott Kitterman wrote:
> On Friday, March 01, 2013 04:43:09 PM William Grant wrote:
>> On 01/03/13 15:46, Martin Pitt wrote:> Loïc Minier [2013-02-28 18:18 +0100]:
 I would think we should go over these questions at UDS next week;
 Steve Langasek has kindly prepared a blueprint from some discussion we
 had on this:
 https://blueprints.launchpad.net/ubuntu/+spec/release-r-monthly-snapshots
>>> Can this be made public? At least to me it appears as a nonexisting
>>> page.
>> It's public, but has been renamed to
>> https://blueprints.launchpad.net/ubuntu/+spec/client-1303-monthly-snapshots
> Thanks for clearing that up.  I don't recall this coming up for me before.  
> It 
> seems a bit odd that if one is subscribed to a spec, you don't get mail for a 
> rename.  Given LP's general habit of verbosity, it's a bit surprising 
> something like this doesn't get mail.
>
I expected it as well, so I filed
https://bugs.launchpad.net/bugs/1137102 since LP didn't send any mail
about it.

Micah

-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: Debian Sync - Re: Let's Discuss Interim Releases (and a Rolling Release)

[Micah Gersten]

On 02/28/2013 11:03 PM, Martin Pitt wrote:
> Micah Gersten [2013-02-28 13:33 -0600]:
>> Yes, but our britney doesn't delay migration to allow for testing of the
>> built packages or block based on RC bugs filed.
> Not on RC bugs, but we can still block them manually. Pinging any
> release team member about that works right now.
>
> What appears to be a crucial prerequisite for this is to integrate our
> autopkgtest results into britney, though.
Well, since we have only a small amount of people that can make a bug RC
(~500), maybe we should socialize a bit more that if there's an RC bug,
the triager should hop into #ubuntu-release and ask for a block to be
put in place.
>> Perhaps if we had our own version of unstable/testing in the rolling
>> release, we could approach that level of quality.
> We have the raring-proposed staging area, which is kind of like that?
No, raring-proposed is only for automatic testing, it's not meant to be
used by end users.  Some bugs don't surface until the software is run as
almost all test suites don't have total code coverage.  As more
autopkgtests are added, I'm sure the number of RC bugs that hit users
will decline, but until test suites in most major software are
comprehensive, having the human testing is quite valuable.

Micah

-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: Debian Sync - Re: Let's Discuss Interim Releases (and a Rolling Release)

[Micah Gersten]

On 02/28/2013 02:11 PM, Jeremy Bicha wrote:
> On 28 February 2013 14:33, Micah Gersten  wrote:
>> Yes, but our britney doesn't delay migration to allow for testing of the
>> built packages or block based on RC bugs filed.  I see us getting to the
>> point at some time in the future of being more stable than testing in a
>> rolling release, but I don't see it right now.  Perhaps if we had our
>> own version of unstable/testing in the rolling release, we could
>> approach that level of quality.  However, being that Debian has
>> maintainers for each package (in theory) and we don't, I'm not sure that
>> Ubuntu has the manpower to do this type of split.
> I think we need to train our britney to block on Debian or Ubuntu RC
> bugs. 
This makes sense.  But, we'd need to be able to flag certain Debian RC
bugs as not affecting Ubuntu where appropriate.

> Maybe this will also allow the Kubuntu developers to package the
> KDE beta updates without needing to worry about those getting picked
> up in the next (monthly?) update cycle.
This won't help as using britney to block migration means that it won't
get testing by end users.

Micah

-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: Debian Sync - Re: Let's Discuss Interim Releases (and a Rolling Release)

[Micah Gersten]

On 02/28/2013 12:17 PM, Dmitrijs Ledkovs wrote:
> On 28 February 2013 17:05, Scott Kitterman  wrote:
>> On Thursday, February 28, 2013 07:31:49 AM Rick Spencer wrote:
>>> Daily Quality means that developers can ensure their components are stable
>>> and useful before they upload, and our processes protect us from most
>>> mistakes these days. The result is that 13.04 has been as robust a release
>>> over the last many weeks as 12.10 was when we delivered. We have achieved
>>> rolling release quality in our development practices, so we can capitalize
>>> on this capability now.
>> Don't forget that Debian has been in Freeze throughout this time.  Once 
>> Wheezy
>> is released, we will start getting a lot more, less mature, packages via
>> Debian sync.   ~75% of the archive comes from Debian unmodified in Ubuntu and
>> the experience during 13.04 development with packages from Debian is 
>> definitely
>> atypical.
>>
>> Also, it is normal to upload beta releases to the development series.  It's a
>> simple fact that they are not going to be as polished as we'd like for 
>> regular
>> users.  You can beat the daily quality drum all you want for Canonical
>> sponsored development effort, but that's not where most of our software comes
>> from.
>>
> But just like debian we know have britney, together with many
> automatic adt tests which we run on all reverse dependencies in
> jenkins. Uploading beta version of software into sid has never been
> welcomed and by default it gets released versions of software. Thus
> I'd expect our devel release to be more stable than testing.
>
Yes, but our britney doesn't delay migration to allow for testing of the
built packages or block based on RC bugs filed.  I see us getting to the
point at some time in the future of being more stable than testing in a
rolling release, but I don't see it right now.  Perhaps if we had our
own version of unstable/testing in the rolling release, we could
approach that level of quality.  However, being that Debian has
maintainers for each package (in theory) and we don't, I'm not sure that
Ubuntu has the manpower to do this type of split.

Thanks,
Micah

-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: Let's Discuss Interim Releases (and a Rolling Release)

[Micah Gersten]

On 02/28/2013 01:02 PM, Steve Langasek wrote:
> Of course, there are some elements of this that are entirely for
> Canonical to decide. For instance, it's Canonical's decision whether
> or not it's going to fund security support for 6-monthly releases. As
> ScottK mentions up-thread, it's doubtful whether anything can be
> called a "supported" release without security support; so if Canonical
> isn't going to provide that 18-month security support for interim
> releases, does it make sense to have those releases? The latter is
> certainly something for the Ubuntu community to decide; for my part I
> think the "correct" answer is obvious, but that doesn't mean I'm not
> willing to discuss it. And for the avoidance of doubt, the calculus
> here is that providing security support for monthly snapshots, which
> will at any given time have no more than 1 month's delta from the
> devel release, will require substantially less manpower than providing
> security support for the interim releases. So this isn't a matter of
> Canonical trying to say "we're willing to do the work this way but not
> that way" in order to force the community to take the decision that
> Canonical wants, it's a real question of reducing maintenance costs.
> If it turns out that monthly snapshots aren't the right way to support
> the community (of both developers and users), there's room for
> discussion of what the right way is. 

I think that people saw this coming as the idea was suggested a while
back in a blog post that I can't seem to find right now.  It was also
said back then that this wouldn't happen until after the 14.04 LTS,
which would have given people another 3 UDSs to sort out details on how
to continue and or migrate to the new way of doing things.  So, with
first the idea that UDS is no longer UDS (now virtual) and second with
what sounds like Canonical not wanting Raring to release as 13.04, I
think there's certainly room to be shocked.  While it seems like it
certainly makes sense for Canonical, the abrupt manner in which it's
being proposed seems most problematic of all, IMHO.

Thanks,
Micah

-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: Minutes from Developer Membership Board Meeting 2013-01-07

[Micah Gersten]

On 02/14/2013 04:26 AM, Sebastien Bacher wrote:
> Le 22/01/2013 11:01, Stefano Rivera a écrit :
 > >We will be sending Bjoern an E-Mail explaining our concerns and
 ways
 > >that he can address them.
>>> >When is that planned? He still didn't get those, we still have no
>>> >clue what to change,
>> As soon as we can. And I think the idea of looking for things to change
>> is short-sighted. If we don't think someone is ready, it usually means
>> they need to do some more good distro work, and show that they are
>> ready.
>>
>
> Hey again,
>
> (Gentle DMB ping, 3 weeks later it seems Bjoern still didn't get that
> explanation email, did it got lost on the way or was it still not sent?)
>
> On other news Benjamin reviewed/sponsored libreoffice 4 to raring,
> thanks Benjamin!
>
> From the review comments/fixes, the issues were mostly small packaging
> issues and cleanups. Benjamin listed one "blocker" issue, which was a
> GLIBCXX symbol listed in the .symbols with a debian revision version,
> that issue was not new in this update and is present in Debian, so it
> can't really be blamed on Bjoern.
>
> Seeing that this update went fine, would the DBM be happy to
> reconsider Bjoern application in the next meeting? Or is there
> anything else you would like to see happening?
>
> If extra work is still needed please let us know what Bjoern should be
> working on/improve, so we can move forward on that application.

I wanted to let you know that it has not been sent, and I apologize for
the delay.  As Iain mentioned, real life has taken precedence for me as
of late, but I do plan on sending the response. If I can't get to it in
the near future, I will look to hand this off.
However, both Stéphane Graber and Benjamin Drung have provided packaging
feedback which will be one of the main issues with PPU shortly as we
(the DMB) are moving to decouple PPU from membership.
Benjamin has mentioned that he's willing to sponsor libreoffice, and has
improved libcdr, libmspub, libvisio to get them acceptable for MIR. 
This should take care of getting LIbreoffice uploaded in the near
future, as well as give Bjoern some valuable sponsor feedback along the way.

Thanks,
Micah

-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: Minutes from Developer Membership Board Meeting 2013-01-07

[Micah Gersten]

On 01/09/2013 01:15 PM, Sebastien Bacher wrote:
> Le 09/01/2013 09:13, Cody A.W. Somerville a écrit :
>>
>> == PerPackageUploader Applications ==
>> === Bjoern Michaelsen for libreoffice ===
>> LINK: https://wiki.ubuntu.com/BjoernMichaelsen/DeveloperApplication
>>
>> VOTE: For: 2 Against: 1 Undecided: 2
>>
>> Application was unsuccessful.
>>
> Hey DMB people,
>
> I've been reading the meeting log and I'm slightly worried that the
> DMB is currently making too hard for contributors to be part of the
> project.
>
> Bjoern has been doing good and hard work on an important package
> (libreoffice) for over 1.5 years, he got strong endorsement from 3
> coredevs and he has been getting in touch with some of the DMB member
> before applying again (his application got rejected already 6 months
> or so ago) and yet that's not enough for him to get ppu on the package
> he's working.
>
> The DMB members who didn't want to +1 his applications mentioned those
> reasons:
>
> - "-1, lack of devel release uploads, still problems with with some
> uploads"
> - "+0 lack of devel release uploads"
> - "+0 [I don't like the idea that we should grant PPU just because
> nobody wants to actually take the time to review this package..."
>
> I've asked on IRC and apparently "lack of devel release uploads" is
> because e.g quantal didn't get SRUs from the current versions.
> Since when is that a reason to not welcome somebody on board?
> Especially when the reason for that is "maintaining the current stable
> is enough for one people full time" ... how is that situation even
> resolvable, libreoffice is not going to be magically less work to
> maintain over time?
>
> The "nobody wants to actually take the time to review this package"
> seems misinformed, the wiki has 3 coredevs vouching for Bjoern who
> have sponsored work for him. I will not speak for pitti and didrocks
> but I've been reviewing the packages I sponsored, I probably didn't do
> a perfect job of it is a complex piece of packaging and I'm not
> familiar with its details.
>
> Could the DMB provides feedback on how to unblock that application?
>
> Since it's re-election time for part of the DMB soon, it would also be
> nice to know what the people, who are going to (re)apply for it, think
> of this situation and if they intend to bring some changes to how the
> board is running if they get elected
>
Upload rights at the moment conflate membership and upload rights.
Therefore, the board has to evaluate the qualifications for both. We do
not, in general, feel that it is fair to publicly enumerate the issues
we have with individual applications, preferring to express our public
concerns in general terms and be more specific in private. We will be
sending Bjoern an E-Mail explaining our concerns and ways that he can
address them.
If he wants, he can choose to share it with anyone after that.

It is not an easy job sitting on a governance board. You're responsible
for evaluating the work of friends and, sometimes, co-workers. While
trying not to hurt feelings or block people's ability to do things, one
also has a responsibility to put personal feelings aside and to consider
the applications received in the context of the wider project.

We always try to be constructive when giving rejections, but it is a
difficult area that we will always be able to improve on. We never take
any decision lightly — especially not rejections — as we are aware of
the negativity they can generate. Most of us are readily available to
discuss and guide applicants. Please find us [1] on IRC if you have any
questions.

Thanks,
Micah Gersten
On behalf of the DMB

[1] https://launchpad.net/~developer-membership-board/+members



-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: [ubuntu/raring-proposed] fglrx-installer-updates 2:9.010-0ubuntu4 (Accepted)

[Micah Gersten]

On 01/21/2013 09:55 AM, Alberto Milone wrote:
> fglrx-installer-updates (2:9.010-0ubuntu4) raring; urgency=low
>
>   * debian/rules:
> - Revert change to separate regen-from-templates from
>   the build target. This fixes a FTBFS.
>
> Date: Mon, 21 Jan 2013 16:49:43 +0100
> Changed-By: Alberto Milone 
> Maintainer: Ubuntu Core Developers 
> https://launchpad.net/ubuntu/raring/+source/fglrx-installer-updates/2:9.010-0ubuntu4
>
Looking at the diff [1], the problem seems to have been a lack of a
build-arch target, not the split out.

Thanks,
Micah


[1]
http://launchpadlibrarian.net/129029705/fglrx-installer-updates_2%3A9.010-0ubuntu3_2%3A9.010-0ubuntu4.diff.gz

-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: raring ringtail test rebuild

[Micah Gersten]

On 01/02/2013 09:58 AM, Matthias Klose wrote:
> A test rebuild of raring ringtail started in 2012 for the amd64, i386 and
> armhf architectures is now finished for all components on armhf. The amd64 and
> i386 rebuilds will hopefully finish in a few days.
>
> Results can be seen at
> http://people.ubuntuwire.org/~wgrant/rebuild-ftbfs-test/test-rebuild-20121221-raring.html
>
> The archive for the test rebuild is
> https://launchpad.net/ubuntu/+archive/test-rebuild-20121221/
>
> Some common build failures are:
>
>  - not finding pyconfig.h, installed into a multiarch include dir
>  - eglibc-2.16 changes (puts).
>
> Please help fixing the build failures for the final release.
>
>   Matthias
>
> PS: For those interested, a second test rebuild using a snapshot of GCC-4.8 is
> going on. Status at
> http://people.ubuntuwire.org/~wgrant/rebuild-ftbfs-test/test-rebuild-20121221-4.8-raring.html
>
>
I was wondering what an upstreamable way to fix the python multiarch dir
issue is.  I've seen some people using python-config --includes (or the
appropriate variable for python-config), but wasn't sure if that was
cross-platform and upstreamable or not.

Thanks,
Micah

-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: Deprecating the wiki-based Packaging Guide

[Micah Gersten]

On 12/18/2012 09:23 AM, Daniel Holbach wrote:
> Hello,
>
> On 18.12.2012 01:52, Scott Kitterman wrote:
>> UDD is not mature or reliable enough to be presented to new users as "the" 
>> way to do packaging for Ubuntu.  I think the current guide is fatally flawed 
>> as is.
>>
>> As soon as a branch is out of date, new users are lost.
> while out-of-date branches and other bits and pieces around UDD are a
> problem, can we please make them a separate discussion?
>
> We can certainly have a discussion about our Development Guide and what
> we recommend in which way. The reality and motivation of the current
> discussion is that two guides are simply confusing and that the Wiki
> documentation hasn't been touched or updated in any meaningful way in ages.
>
> I'd suggest we agree on one guide and then figure out what we recommend,
> rewrite or improve in there. This shouldn't be a blocker for obsoleting
> one of the guides.
>
> Have a great day,
>  Daniel
>
I think the point is that the new guide would have to include the
pull-lp-source/debdiff/attach to bug route as well before some of us are
comfortable deleting that information from the Wiki.  It's not so much
where it lives as that it's available as a fallback.
Thanks,
Micah

-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: [ubuntu/raring-proposed] libunity-webapps 2.4.3daily12.11.29-0ubuntu1 (Accepted)

[Micah Gersten]

On 11/29/2012 10:29 AM, Sebastien Bacher wrote:
> Le 29/11/2012 17:04, Micah Gersten a écrit :
>> I'm actually more concerned from the archive side than the project
>> side of this.  I'm wondering if there are uploads that aren't worth
>> doing which ends up wasting build time, storage space, and bandwidth.
>
> Hey Micah,
>
> Yes, the process is quite new and it might be it's not optimal yet...
>
> What about watching how things goes for a bit, and see if in practice
> there are lot of cases where a daily upload happen without useful
> content?
> If that's a common case, I'm sure we can figure out a way to improve
> the system to not trigger new builds for those (e.g have a list of
> files to ignore when we consider the daily update).
>
> Sebastien Bacher
>
Right, that's what I would like to do, but it's hard to tell if there's
useful content or not with no information in the changelog :)

Thanks,
Micah

-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Launchpad fail, please ignore: Re: Daily snapshot changelogs don't reflect diff

[Micah Gersten]

On 11/29/2012 10:09 AM, Micah Gersten wrote:
> On 11/29/2012 09:59 AM, Ubuntu Archive Robot wrote:
>> xpathselect (1.1.3daily12.11.29.2-0ubuntu1) raring; urgency=low
>>
>>   [ Mathieu Trudel-Lapierre ]
>>   * Automatic snapshot from revision 1 (bootstrap).
>>   * debian/control:
>> - Update style: use trailing commas at the end of dep lists.
>> - Bump Build-Depends on debhelper to (>= 9).
>> - Add Vcs-Bzr, Vcs-Browser and a notice to uploaders.
>> - Fix typos in descriptions.
>> - Renamed libxpathselect to libxpathselect1.1 to follow soname.
>> - Adjust short description for libxpathselect-dev.
>> - Adjust long description for libxpathselect-dev.
>> - Fix Depends on libxpathselect1.1 for libxpathselect-dev.
>> - Add Pre-Depends:, Multi-Arch: to libxpathselect1.1.
>>   * debian/compat: bump to compat level 9.
>>   * debian/rules:
>> - Override dh_install to remove *.la/*.a files and fail the build if 
>> there
>>   are files not being installed or missing from the build.
>> - Add and export DPKG_GENSYMBOLS_CHECK_LEVEL.
>> - Override dh_auto_test to properly run tests via test-runner.
>> - Override dh_makeshlibs to strictly check symbols.
>>   * debian/source/format: migrate back to source format 1.0.
>>   * debian/libxpathselect.install: renamed to 
>> debian/libxpathselect1.1.install
>>   * debian/*.install: update paths for multiarch.
>>
>>   [ Automatic PS uploader ]
>>   * Automatic snapshot from revision 24
>>
>> Date: 2012-11-29 12:45:22.068013+00:00
>> Changed-By: PS Jenkins bot 
>> Signed-By: Ubuntu Archive Robot 
>> 
>> https://launchpad.net/ubuntu/raring/+source/xpathselect/1.1.3daily12.11.29.2-0ubuntu1
>>
> The diff tells a very different story than the changelog here:
> http://launchpadlibrarian.net/124404549/xpathselect_1.1.3daily12.11.29.1-0ubuntu1_1.1.3daily12.11.29.2-0ubuntu1.diff.gz
>
> The only thing updated was debian/copyright.
>
> Thanks,
> Micah
>
Nevermind, this is a Launchpad issue.  This was a new package and for
some reason, Launchpad diffed against an old version.
I really need to get some coffee...sorry for the noise.
Micah

-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Daily snapshot changelogs don't reflect diff (was: Re: [ubuntu/raring-proposed] xpathselect 1.1.3daily12.11.29.2-0ubuntu1 (Accepted))

[Micah Gersten]

On 11/29/2012 09:59 AM, Ubuntu Archive Robot wrote:
> xpathselect (1.1.3daily12.11.29.2-0ubuntu1) raring; urgency=low
>
>   [ Mathieu Trudel-Lapierre ]
>   * Automatic snapshot from revision 1 (bootstrap).
>   * debian/control:
> - Update style: use trailing commas at the end of dep lists.
> - Bump Build-Depends on debhelper to (>= 9).
> - Add Vcs-Bzr, Vcs-Browser and a notice to uploaders.
> - Fix typos in descriptions.
> - Renamed libxpathselect to libxpathselect1.1 to follow soname.
> - Adjust short description for libxpathselect-dev.
> - Adjust long description for libxpathselect-dev.
> - Fix Depends on libxpathselect1.1 for libxpathselect-dev.
> - Add Pre-Depends:, Multi-Arch: to libxpathselect1.1.
>   * debian/compat: bump to compat level 9.
>   * debian/rules:
> - Override dh_install to remove *.la/*.a files and fail the build if there
>   are files not being installed or missing from the build.
> - Add and export DPKG_GENSYMBOLS_CHECK_LEVEL.
> - Override dh_auto_test to properly run tests via test-runner.
> - Override dh_makeshlibs to strictly check symbols.
>   * debian/source/format: migrate back to source format 1.0.
>   * debian/libxpathselect.install: renamed to debian/libxpathselect1.1.install
>   * debian/*.install: update paths for multiarch.
>
>   [ Automatic PS uploader ]
>   * Automatic snapshot from revision 24
>
> Date: 2012-11-29 12:45:22.068013+00:00
> Changed-By: PS Jenkins bot 
> Signed-By: Ubuntu Archive Robot 
> 
> https://launchpad.net/ubuntu/raring/+source/xpathselect/1.1.3daily12.11.29.2-0ubuntu1
>
The diff tells a very different story than the changelog here:
http://launchpadlibrarian.net/124404549/xpathselect_1.1.3daily12.11.29.1-0ubuntu1_1.1.3daily12.11.29.2-0ubuntu1.diff.gz

The only thing updated was debian/copyright.

Thanks,
Micah

-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: [ubuntu/raring-proposed] libunity-webapps 2.4.3daily12.11.29-0ubuntu1 (Accepted)

[Micah Gersten]

On 11/29/2012 09:44 AM, Didier Roche wrote:
> Le 29/11/2012 16:37, Micah Gersten a écrit :
>> On 11/29/2012 09:26 AM, Didier Roche wrote:
>>> Le 29/11/2012 16:12, Micah Gersten a écrit :
>>>> On 11/29/2012 04:45 AM, Ubuntu Archive Robot wrote:
>>>>> libunity-webapps (2.4.3daily12.11.29-0ubuntu1) raring; urgency=low
>>>>>
>>>>>   * Automatic snapshot from revision 866
>>>>>
>>>>> Date: 2012-11-29 08:00:12.447090+00:00
>>>>> Changed-By: PS Jenkins bot 
>>>>> Maintainer: Ubuntu Desktop 
>>>>> Signed-By: Ubuntu Archive Robot 
>>>>> 
>>>>> https://launchpad.net/ubuntu/raring/+source/libunity-webapps/2.4.3daily12.11.29-0ubuntu1
>>>>>
>>>> Could we please have more verbose changelogs about what has changed than
>>>> this?
>>> Hey Micah,
>>>
>>> The changelog is generated from all the bugs attached to the branch
>>> from the developers. So, if the developers attached no bug to a
>>> branch and doesn't file the NEWS file, it will be empty, as you can
>>> see with most of the uploads we have in GNOME and others "New
>>> upstream release".
>>>
>>> When people are actually doing this, you get even more info than a
>>> simple upload you do manually, see for instance:
>>>
>>> https://lists.ubuntu.com/archives/raring-changes/2012-November/001547.html
>>> where you get the upstream committer name.
>>>
>> That's fine if it's a new upstream release as that means that someone
>> has manually signed off on it as a release containing new content
>> worth making a release for.  Here, as an automated process, I think
>> it's more problematic if there's no entry explaining why the upload
>> was done.  The commits might be rather useless and not really warrant
>> an upload.  It might be possible to refine the automation further to
>> skip such useless uploads.  I'm wondering, if there's no bug or NEWS
>> entry, if the bzr commit message should be used.
>
> I tried as the first approach to use the commit message if no bug was
> attached, but the changelog did sound really noisy and I think that
> what we are really interested in are the bugs that are closed in an
> upload. You still have the debdiff if you want to have the full story
> of what's new inside (or the upstream vcs which is listed in
> debian/control). I think people interested enough in addition to the
> team monitoring those upstream projects can have a look there.
>
I'm actually more concerned from the archive side than the project side
of this.  I'm wondering if there are uploads that aren't worth doing
which ends up wasting build time, storage space, and bandwidth.

Thanks,
Micah
-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: [ubuntu/raring-proposed] libunity-webapps 2.4.3daily12.11.29-0ubuntu1 (Accepted)

[Micah Gersten]

On 11/29/2012 09:26 AM, Didier Roche wrote:
> Le 29/11/2012 16:12, Micah Gersten a écrit :
>> On 11/29/2012 04:45 AM, Ubuntu Archive Robot wrote:
>>> libunity-webapps (2.4.3daily12.11.29-0ubuntu1) raring; urgency=low
>>>
>>>   * Automatic snapshot from revision 866
>>>
>>> Date: 2012-11-29 08:00:12.447090+00:00
>>> Changed-By: PS Jenkins bot 
>>> Maintainer: Ubuntu Desktop 
>>> Signed-By: Ubuntu Archive Robot 
>>> 
>>> https://launchpad.net/ubuntu/raring/+source/libunity-webapps/2.4.3daily12.11.29-0ubuntu1
>>>
>> Could we please have more verbose changelogs about what has changed than
>> this?
> Hey Micah,
>
> The changelog is generated from all the bugs attached to the branch
> from the developers. So, if the developers attached no bug to a branch
> and doesn't file the NEWS file, it will be empty, as you can see with
> most of the uploads we have in GNOME and others "New upstream release".
>
> When people are actually doing this, you get even more info than a
> simple upload you do manually, see for instance:
>
> https://lists.ubuntu.com/archives/raring-changes/2012-November/001547.html
> where you get the upstream committer name.
>
That's fine if it's a new upstream release as that means that someone
has manually signed off on it as a release containing new content worth
making a release for.  Here, as an automated process, I think it's more
problematic if there's no entry explaining why the upload was done.  The
commits might be rather useless and not really warrant an upload.  It
might be possible to refine the automation further to skip such useless
uploads.  I'm wondering, if there's no bug or NEWS entry, if the bzr
commit message should be used.

Thanks,
Micah
-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: [ubuntu/raring-proposed] libunity-webapps 2.4.3daily12.11.29-0ubuntu1 (Accepted)

[Micah Gersten]

On 11/29/2012 04:45 AM, Ubuntu Archive Robot wrote:
> libunity-webapps (2.4.3daily12.11.29-0ubuntu1) raring; urgency=low
>
>   * Automatic snapshot from revision 866
>
> Date: 2012-11-29 08:00:12.447090+00:00
> Changed-By: PS Jenkins bot 
> Maintainer: Ubuntu Desktop 
> Signed-By: Ubuntu Archive Robot 
> 
> https://launchpad.net/ubuntu/raring/+source/libunity-webapps/2.4.3daily12.11.29-0ubuntu1
>
Could we please have more verbose changelogs about what has changed than
this?

Thanks,
Micah

-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Patch Pilot report 2012/10

[Micah Gersten]

https://code.launchpad.net/~roadmr/ubuntu/quantal/checkbox/0.14.8/+merge/127923
 - needs FFe, unsubscribed sponsors

Bug #1057518 - onboard 0.98.1 update
 - needs UIFe, unsubscribed sponsors, add release tracking tag

Sync gummi 0.6.3-1.2 (universe) from Debian unstable (main)
Sync robocode 1.6.2+dfsg-3.1 (universe) from Debian unstable (main)
Sync prewikka 1.0.0-1.2 (universe) from Debian unstable (main)
Sync nufw 2.4.3-2.2 (universe) from Debian unstable (main)
 - syncd, in queue

[FFe] Please transition openmotif to multi-arch
 - reset to New so release team sees it

[Quantal] Regression in TLS 1.2 workarounds - Bug #1051892
 - looks fine, uploaded

Sync sope 1.3.16-1 (universe) from Debian unstable (main)
 - since sogo was already in, we sync'd this as well

https://code.launchpad.net/~jtaylor/ubuntu/quantal/valgrind/various-fixes/+merge/128314
 - uploaded
--
Micah Gersten
Ubuntu Security Team

--
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Patch Pilot 2012-09-10 - 2012-09-11

[Micah Gersten]

[FFE] Sync qxmpp 0.7.3-1 (universe) from Debian unstable (main) - syncd

aptitude can no longer show changelogs: "Changelog download failed:
  Download queue destroyed." (LP: #824708)  - sponsored for SRU

Input Method Switcher does not open from the menu Preferences/input
  method switcher or from the File manager PCmanfm /prefernces/input
  method switcher (LP: #1041941)  - sponsored

FFe: Sync wader 0.5.12-1 (universe) from Debian unstable (main) - syncd

Add the xchat-indicator package as a Recommends for xchat (LP: #1048833)
 - rejected since it's useless in environments without an indicator, suggested 
adding an Enhances: xchat on the indicator package

Commented on
https://code.launchpad.net/~jan-hrdina/ubuntu/quantal/xfce4-places-plugin/1.4.0-upstream-import/+merge/122267
 - needs more information if it needs a UIFe or not

[FFE] support emulated systems w/ > 2G of memory (LP: #1030588):
unsubscribed sponsors, needs FFe

[FFE] enable flat device tree support (LP: #1030594): unsubscribed
sponsors, needs FFe

https://code.launchpad.net/~alessandro-menti/ubuntu/precise/kile/fix-for-994498/+merge/118919
https://code.launchpad.net/~geoubuntu/ubuntu/precise/xmltv/1018756/+merge/118935
  - already uploaded, had marked Work in Progress to remove from queue

GTK Print dialog sends broken custom page size attribute:
"PageSize=Custom.Custom.x"  (LP: #998156)
  - larsu in #ubuntu-desktop said the patch wasn't upstreamable, marked
patch as needswork and unsubscribed sponsors

at boot, the font is not set by the upstart job (LP: #433897) -
unsubscribed sponsors, cjwatson handling

flash-kernel shouldn't prompt the user when updating initramfs in case
there's no valid /etc/fstab (LP: #1034734)
  - unsubscribe sponsors, rsalveti is now core-dev and can handle this
himself

Bug #1049194 - Make the xchat-indicator package "Enhances:" xchat -
sponsored and committed to bzr, needed a little fixing (this was the
same xchat-indicator issue mentioned above)

Sync abe 1.1+dfsg-1 (universe) from Debian unstable (main) (LP:
#1049315), builds, sync'd

Sync circos 0.61-3 (universe) from Debian unstable (main) (LP:
#1049323), needs FFe for binary rename

Queue at 52 ATM

-- 
Micah Gersten
Ubuntu Security Team


-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: Proposing a New App Developer Upload Process

[Micah Gersten]

On 09/05/2012 11:46 AM, Didier Roche wrote:
> Le 05/09/2012 16:26, David Planella a écrit :
>> Al 05/09/12 14:29, En/na Scott Kitterman ha escrit:
>>>
>>> David Planella  wrote:
>>>
 * File name conflicts: there I would suggest exploring Daniel's
 proposal
 of relying on a conflict checker that works across all archives, so
 that
 before an upload is accepted this service checks for any potential
 clashes and informs the uploader to fix the package before they can do
 the next submission. The uploader would either be an Ubuntu developer
 (through the main archive) or an app developer (through extras, via
 MyApps). This would not only benefit the app developer process, but
 also
 fix the existing issue in the regular Ubuntu upload process.
>>> This would be useful, but insufficient.
>>>
>> Could you elaborate on why you think it would be insufficient and what
>> alternative you believe would be a solution for file name conflicts in
>> this context?
>>
 * Namespace ownership: even with conflict checking there is the issue
 of
 who gets to own a particular file name or namespace. E.g. would "Mad
 Feathered Creatures" (/usr/bin/birds, from Extras) have priority in
 owning the binary's name if it had been submitted before "Jolly Flying
 Animals" (also /usr/bin/birds, from Universe)? I think if we want to
 make apps first-class citizens, even if not part of the distro, a
 simple
 suggestion would just be to do it on a first-come-first-serve basis.
>>> I think it is fundamentally incorrect to give something built on
>>> Ubuntu namespace priority over Ubuntu itself. Additionally, if this
>>> service proves popular, this approach would drive a permanent
>>> namespace wedge between Debian and Ubuntu that might, over time,
>>> significanly change the nature of the relationship between the two
>>> distributions.
>>>
>> I can see the point of the namespace wedge if we become immensely
>> popular. What do you think the alternatives are?
>>
 What are your thoughts on these?

 Finally, I believe we do need to provision for those cases, but my
 understanding is that the potential amount of occurrences would be
 rather low. So do you think they justify additional Engineering work,
 or
 rather they could be dealt manually on a case-by-case basis?

>>> You've got to consider it now or it won't scale.  IIRC the original
>>> presentations on this topic at UDS Orlando(?), the intent was to be
>>> able to scale out to hit numbers of applications equal to or greater
>>> than the Apple Appstore/Google Play.  If you hit that, then MyApps
>>> ends up being several times the size of the Ubuntu archive.
>>>
>> And that's what we're doing right now. My only concern is not to block
>> on a situation that will concern just a fraction of the uploads, even at
>> a higher scale. That's what I'm trying to get a feel for.
>
> For all those 3 namespacing/files issues, maybe we can think of a
> simple solution.
>
> I really like Daniel 's idea of a conflict-check-before-publish
> service. One of the case that was raised on the thread is about "you
> can't predict the future". What about that example taking back the
> "Mad feathered creatures" shipping /usr/bin/birds
> - in precise, only the apps from extras is there
> - in quantal, we sync from debian, or upload directly to universe
> "Jolly Flying Animals" which ships the same file (new package or update)
> -> nothing happens at this stage (remember that extras is not opened)
> - a little bit (like 3 weeks?) before opening extras, we run (and then
> continuously run) the conflict-check-before-publish service. This one
> will detect the new conflict between the two packages, and:
> 1. add a Conflicts: in "Mad feathered creatures" debian/control file
> in extras against the package in universe.
> 2. will send an email to the app developer telling "hey, maybe not all
> ubuntu user will be able to use your apps as there is this excellent
> new application <…> into the archive"
>
> At the extreme, if the component in conflict is a core component, as
> the ubuntu archive have an higher priority than the extra one
> (right?), then the core component will be preferred on dist-upgrade.
> This has the advantage of:
> - pushing the burden to the app developer, not to ubuntu developers
> - avoid having to do conflicts/replaces on our side and so diverging
> from debian
> - by pushing the burden to the app developer, still having a automatic
> update solution integrated into myapps, but mailing them, we ensure to
> have people committed to their application in ubuntu
>
> I think this solution would fit for what will really be and stay,
> IMHO, a corner case. I doubt with all the precautions taken into the
> naming and namespace that will happen with every cycles and the few
> developers in that case will be warned and have time to react before
> the extras opening. In case they don't react, we hav

Minutes from the Developer Membership Board meeting (Mon Aug 13)

[Micah Gersten]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

The Developer Membership Board (DMB) met on Mon Aug 13 at 19:00 UTC.

Chair:

  * micahg

Attendees:

  * stgraber
  * bdrung
  * tumbleweed
  * barry

Guests:

  * dupondje
  * xnox

Apologies:

  * Laney
  * cody-somerville


== MOTU application for Jean-Louis Dupond ==
The DMB reviewed this application, but after much discussion, decided to
ask Jean-Louis to return in a few months.


==what to do when uploaders no longer have the CoC signed ==

The DMB has decided that any Ubuntu developers that no longer have the
Ubuntu Code of Conduct signed will be deactivated pending signing the CoC.
We currently only have one uploader in this situation who will be
removed until he signs the CoC.

stgraber took an action to clean up coredev/motu duplicate package set
rights (such as a situation where a core dev or MOTU has PPU unnecessarily)

The concept of unused packagesets were discussed and there was an action
item given to laney with tumbleweed as a backup to contact the uploaders
of unused packagesets.

next chair: cody-somerville (laney)

Full log here:
http://ubottu.com/meetingology/logs/ubuntu-meeting/2012/ubuntu-meeting.2012-08-13-19.09.log.html


-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)

iEYEARECAAYFAlA7faAACgkQTniv4aqX/VlwmgCfVVjZYQuwP3hULRuYjq6zDBui
Jw0An2JGwJYiotHd46Wyc4dv436Dz/Cu
=R6r9
-END PGP SIGNATURE-


-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: dropping old video drivers (was: new xorg stack in quantal-proposed)

[Micah Gersten]

On 08/02/2012 03:15 PM, Timo Aaltonen wrote:
> 
> I didn't push updates for obsolete video drivers not depended on by
> xserver-xorg-video-all, since I think it's probably time to remove them
> from the archive (we dropped them from -video-all for 11.10). This
> includes -apm, -ark, -chips, -glide, -glint, -i128, -i740, -rendition,
> -s3virge, -tseng, -voodoo. Both users of such hw can still use 12.04 for
> the next ~5y.
>
I would think as long as these cards are usable in machines still
supported by the kernel, it would be great to keep them (if there's not
an unreasonable amount of maintenance; I don't think rebuilds for each
new xorg stack qualifies).  I would think most of that work would be
done in Debian as well.  If Debian has dropped them, then by all means
follow suit.

Thanks,
Micah

-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: coloring of sponsoring items

[Micah Gersten]

On 07/23/2012 05:31 PM, Benjamin Drung wrote:
> Am Montag, den 23.07.2012, 17:20 -0500 schrieb Jamie Strandboge:
>> Pleased to see that the queue was in good shape.
> Should we adjust the coloring of the sponsoring items? The current
> behavior is to use a yellow background color for items that are older
> than two weeks and a red background color for items that are older than
> four weeks. Should we reduce these durations to one week for yellow, two
> weeks for orange, and three weeks for red?
>
This sounds good to me, it's more incentive to keep the queue under
control.  :)
This would currently give us 1 orange, 5 yellow, and 9 uncolored instead
of the 1 yellow we have now.

Micah

-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: System indicators will drop GTK2 support in quantal

[Micah Gersten]

On 06/29/2012 11:21 AM, Sebastien Bacher wrote:
> Hi,
>
> I'm not sure how well that got communicated after UDS so I'm sending
> an email to the devel list.
>
> With the LTS out the dx indicators' team is dropping gtk2 support for
> indicator-* this cycle (i.e the system indicators:
> indicator-session,messages,etc), they will still keep gtk2 versions of
> the libraries so there should be no issue for applications.
>
> I'm not sure what are the plans e.g xfce and GTK3 and if indicators
> are used there but if that's an issue for xubuntu or other derivates
> please let us know which ones you need so we can work together on a
> solution (which could be to upload a different source with the precise
> version of the needed indicators to build with gtk2 for example).
>
> -- 
> Sebastien Bacher
>
Unfortunately, Xfce's plans to migrate to GTK3 were pushed off, so I
think we're going to need a GTK2 version of the indicator stack for the
time being.
Here's what Xubuntu is currently using:

indicator-application   | 
indicator-application | libappindicator3-1 (Recommends) 
   | Ubuntu Desktop Team   
 |   30286 | 152
indicator-application-gtk2  | 
indicator-application | Xubuntu.Quantal desktop seed
   | Ubuntu Desktop Team   
 |   11626 |  94
indicator-messages  | 
indicator-messages| indicator-messages-gtk2 
   | Ubuntu Developers   
 |   69044 | 345
indicator-messages-gtk2 | 
indicator-messages| xfce4-indicator-plugin (Recommends) 
   | Ubuntu Developers   
 |   11496 |  84
indicator-sound | indicator-sound   
| indicator-sound-gtk2   | Ubuntu 
Desktop Team|  
106116 | 359
indicator-sound-gtk2| indicator-sound   
| Xubuntu.Quantal desktop seed   | Ubuntu 
Desktop Team|   
33906 | 124
indicator-status-provider-mc5   | 
indicator-messages| indicator-messages (Recommends) 
   | Ubuntu Developers   
 |6206 |  76
indicator-status-provider-pidgin| 
indicator-messages| pidgin-libnotify (Recommends)   
   | Ubuntu Developers   
 |6848 |  80


Thanks,
Micah

-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: [ubuntu/quantal] jquery 1.7.2+debian-1ubuntu1 (Accepted)

[Micah Gersten]

On 06/04/2012 08:05 AM, Yolanda Robla wrote:
> jquery (1.7.2+debian-1ubuntu1) quantal; urgency=low
>
>   * Merge from Debian unstable (LP: #1006866).
> - Drop Recommends: javascript-common to a Suggests:; there's no reason
>   we need to publish these scripts via http by default.
>   * Back to yui-compressor instead of uglify
>   * Removing applied patch
>   * Added patch to use yui-compressor on makefile
>   * added yuicompressor to Build-Depends again
>
> jquery (1.7.2+debian-1) unstable; urgency=high
>
>   * Distfile does not contain complete source code (Closes: #665968)
> + Repacking tarball to add necessary build files
> + Using uglify to minify files
> + Updating copyright file
>
> jquery (1.7.2-1) unstable; urgency=low
>
>   * New upstream release
>   * Updated Standards-Version to 3.9.3
> + Machine-readable debian/copyright version 1.0
>
> Date: Mon, 04 Jun 2012 10:51:09 +0200
> Changed-By: Yolanda Robla 
> Maintainer: Ubuntu Developers 
> Signed-By: Daniel Holbach 
> https://launchpad.net/ubuntu/quantal/+source/jquery/1.7.2+debian-1ubuntu1
>
Why are we diverging from Debian here?  There is no bug or reason given
for this in the changelog.
Thanks,
Micah

-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: [ubuntu/quantal] gource 0.38-1ubuntu1 (Accepted)

[Micah Gersten]

On 05/28/2012 02:20 PM, Ilya Barygin wrote:
> gource (0.38-1ubuntu1) quantal; urgency=low
>
>   * Change build dependency to libglew-dev to make sure we're building
> with libglew1.7.
>
>
I don't think we should be doing this.  Once krita (1.5) and nux (1.6)
are switched to glew 1.7, we should drop the glew 1.5 (unnecessary
glew1.5 source) and 1.6 (NBS) dev packages so we don't end up with
unnecessary diffs.

Thanks,
Micah

-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: dh_python2 and /usr/share/pyshared in quantal

[Micah Gersten]

On 05/22/2012 09:07 PM, Stefano Rivera wrote:
>>> Do we really need to break the archive version to figure those out,
>>> can't we do an archive rebuild of some way using a custom or ppa build?
>> An i386 rebuild should be sufficient for this.
> I'd have thought a grep through the lintian lab would be sufficient?
That would probably work too :)

Micah

-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: dh_python2 and /usr/share/pyshared in quantal

[Micah Gersten]

On 05/22/2012 12:22 PM, Sebastien Bacher wrote:
> Le 22/05/2012 17:33, Barry Warsaw a écrit :
>> Matthias made the change to try to catch unnecessary (invalid?) uses of
>> pyshared, which might a worthy goal
> Hey,
>
> Do we really need to break the archive version to figure those out,
> can't we do an archive rebuild of some way using a custom or ppa build?
>
> Sebastien Bacher
>
An i386 rebuild should be sufficient for this.  As the builders have
been mostly idle and a rebuild on i386 should be done before alpha1
week, maybe now is a good time?

-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: Quantal archive rebuild proposal

[Micah Gersten]

On 04/27/2012 06:23 PM, Steve Langasek wrote:
> On Fri, Apr 27, 2012 at 06:11:38PM -0500, Micah Gersten wrote:
>> On 04/27/2012 06:00 PM, Steve Langasek wrote:
>>> On Fri, Apr 27, 2012 at 05:46:50PM -0500, Micah Gersten wrote:
>>>> Now that we can use -proposed during development, the only arch skew
>>>> should be from autosyncs.
>>> I don't think that's a realistic assessment of how -proposed will be used in
>>> practice.  We should not be duplicating the entirety of Debian's testing
>>> propagation - doing so would bring a whole set of other problems that we are
>>> not currently set up to handle.
>> The main arch skew issues in the past regarding builds as I remember
>> them are glib, gtk, and openjdk which we all upload directly.  Wasn't
>> the intent to use proposed for these updates during the devel cycle?
> We should use -proposed for *select* uploads to the development release. 
> But you said "the only arch skew should be from autosyncs", which I do not
> expect to be true at all. :)
Yes, of course, we're not replacing the testing migration from Debian,
nor will every potential skew upload go through -proposed. However, arch
skews should be less than in past releases now that we can use -proposed
for potentially disruptive uploads.
Micah

-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: Quantal archive rebuild proposal

[Micah Gersten]

On 04/27/2012 06:00 PM, Steve Langasek wrote:
> On Fri, Apr 27, 2012 at 05:46:50PM -0500, Micah Gersten wrote:
>> Now that we can use -proposed during development, the only arch skew
>> should be from autosyncs.
> I don't think that's a realistic assessment of how -proposed will be used in
> practice.  We should not be duplicating the entirety of Debian's testing
> propagation - doing so would bring a whole set of other problems that we are
> not currently set up to handle.
>
>
>
The main arch skew issues in the past regarding builds as I remember
them are glib, gtk, and openjdk which we all upload directly.  Wasn't
the intent to use proposed for these updates during the devel cycle?
Micah
-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: Quantal archive rebuild proposal

[Micah Gersten]

On 04/27/2012 05:46 PM, Micah Gersten wrote:
> On 04/27/2012 05:20 PM, Scott Kitterman wrote:
>> On Friday, April 27, 2012 05:13:21 PM Micah Gersten wrote:
>>> Now that we have the faster i386/amd64 buildds, I'd like to suggest at
>>> least one extra rebuild earlier in the cycle at least for i386/amd64 so
>>> there's time to get these changes upstream.
>>>
>>> Around alpha 1 ~ June 7 (archive raw, lots of failures, should catch
>>> most of the Ubuntu change related gcc-4.7 issues though)
>>> After Feature freeze ~ Aug 23 (archive should be fairly stable for most
>>> dependency trees, check to see what new failures were introduced through
>>> new upstream versions)
>>> During beta 2 freeze ~ Sep 25 (shake out the last round of failures)
>> My initial reaction is that we're learning plenty from the existing 
>> rebuilds.  
>> There's no real need to add to the pile of work we don't have time to do.
>>
>> The rebuilds do have a negative effect on distro development because, even 
>> though they have a low priority in Soyuz, when all the builders are full due 
>> to rebuild packages being built nothing can start until one of the rebuild 
>> packages finishes.  Since they build in alphabetical order, about the time 
>> you 
>> hit gcc*, this can really slow things up.
>>
>> I would not add more rebuilds unless it's really clear there will be 
>> benefit.  
>> Until after DIF much of what turns up in a rebuild is inevitably archive 
>> skew 
>> that it's not hard to find other ways.
>>
>> Scott K
>>
> Now that we can use -proposed during development, the only arch skew
> should be from autosyncs.  The current failures do tell us a lot, but
> quite a few will probably be fixed with the autosyncs as well.
> Remaining failures from the last rebuild in precise:
>
>   Main archivePorts archive
> i386  amd64   armhf
> arch (F)  Package failed to build <="" td="">
>   <="" td="">
>   <="" td="">
> arch (M)  Package is waiting on another package   <="" td="">
>   <="" td="">
>   <="" td="">
>
>
> So, most of the armhf failures are related to gnat-4.6 not being
> available.  That leaves a little more than 100 failures some of which
> will be resolved with autosyncs (also most are probably not easy
> fixes).  A new rebuild would give people a chance to pick off easy
> fixes and also let us know where we stand WRT new failures early on.
> So, maybe we should wait until after DIF, then there would be very
> little risk of archive skew during the rebuild.
> Another thing to consider, is with Debian freezing for Wheezy at some
> point, the likelihood of fixes from new upstream versions getting in
> through Debian decreases as we get further into the cycle.
>
> Micah
>
>
Sorry, the numbers were apparently lost on send:
Failure type
Main archive Ports archive
   
 i386amd64armhf
arch (F) Package failed to build  116 85
148
arch (M) Package is waiting on another package 9 7 105
-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: Quantal archive rebuild proposal

[Micah Gersten]

On 04/27/2012 05:20 PM, Scott Kitterman wrote:
> On Friday, April 27, 2012 05:13:21 PM Micah Gersten wrote:
>> Now that we have the faster i386/amd64 buildds, I'd like to suggest at
>> least one extra rebuild earlier in the cycle at least for i386/amd64 so
>> there's time to get these changes upstream.
>>
>> Around alpha 1 ~ June 7 (archive raw, lots of failures, should catch
>> most of the Ubuntu change related gcc-4.7 issues though)
>> After Feature freeze ~ Aug 23 (archive should be fairly stable for most
>> dependency trees, check to see what new failures were introduced through
>> new upstream versions)
>> During beta 2 freeze ~ Sep 25 (shake out the last round of failures)
> My initial reaction is that we're learning plenty from the existing rebuilds. 
>  
> There's no real need to add to the pile of work we don't have time to do.
>
> The rebuilds do have a negative effect on distro development because, even 
> though they have a low priority in Soyuz, when all the builders are full due 
> to rebuild packages being built nothing can start until one of the rebuild 
> packages finishes.  Since they build in alphabetical order, about the time 
> you 
> hit gcc*, this can really slow things up.
>
> I would not add more rebuilds unless it's really clear there will be benefit. 
>  
> Until after DIF much of what turns up in a rebuild is inevitably archive skew 
> that it's not hard to find other ways.
>
> Scott K
>
Now that we can use -proposed during development, the only arch skew
should be from autosyncs.  The current failures do tell us a lot, but
quite a few will probably be fixed with the autosyncs as well.
Remaining failures from the last rebuild in precise:

Main archivePorts archive
i386amd64   armhf
arch (F)Package failed to build 116 85  148
arch (M)Package is waiting on another package   9   7   105


So, most of the armhf failures are related to gnat-4.6 not being
available.  That leaves a little more than 100 failures some of which
will be resolved with autosyncs (also most are probably not easy
fixes).  A new rebuild would give people a chance to pick off easy fixes
and also let us know where we stand WRT new failures early on.
So, maybe we should wait until after DIF, then there would be very
little risk of archive skew during the rebuild.
Another thing to consider, is with Debian freezing for Wheezy at some
point, the likelihood of fixes from new upstream versions getting in
through Debian decreases as we get further into the cycle.

Micah
-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Quantal archive rebuild proposal

[Micah Gersten]

Now that we have the faster i386/amd64 buildds, I'd like to suggest at
least one extra rebuild earlier in the cycle at least for i386/amd64 so
there's time to get these changes upstream.

Around alpha 1 ~ June 7 (archive raw, lots of failures, should catch
most of the Ubuntu change related gcc-4.7 issues though)
After Feature freeze ~ Aug 23 (archive should be fairly stable for most
dependency trees, check to see what new failures were introduced through
new upstream versions)
During beta 2 freeze ~ Sep 25 (shake out the last round of failures)

Thoughts?

Thanks,
Micah

-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: Planning for Quantal: Boost

[Micah Gersten]

On 04/25/2012 05:52 PM, Scott Kitterman wrote:
> The current upstream Boost release is 1.49.  This is also the default in 
> Debian.  We should transition to that as the default for Quantal when archive 
> is set up (before general uploading starts).
>
> boost-defaults will need to be synced and boost1.49 will have to be uploaded 
> and split, and put in Main.  We'll also need to create a boost-mpi-source1.49 
> for the MPI related bits that can't go in Main.
>
> As long as there's agreement that this is the right thing to do (I don't know 
> what else we'd do) I can take care of this.  It does need to be in place 
> before the first autosync run.
>
> Scott K
>
Sounds good to me (not-authoritative).   We should probably get a
transition tracker set up for this as well.

Micah

-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Patch Pilot Apr 16-Apr 19

[Micah Gersten]

sponsor refpolicy-ubuntu FTBFS fix - (LP: #935407)

iterate with contributor on
https://code.launchpad.net/~cairo-dock-team/ubuntu/precise/cairo-dock-plug-ins/984054/+merge/102353
and sponsor cairo-dock-plug-ins (3.0.0.1-0ubuntu2) (LP: #984054)

Please remove wesnoth-1.8 from precise - bug 982534
 - deemed unnecessary as the source has use for people upgrading to precise

Reviewed 965645 <https://launchpad.net/bugs/965645> - Error starting
ConVirt - Marked as triaged for the task with a patch, incomplete for
the task that we're waiting on the reporter

https://code.launchpad.net/~nathwill/ubuntu/precise/pam/lp-10287/+merge/100282
  - Asked for review from Steve Langasek (figure this can go into Debian
now if it's worthy), too late for precise before release, Steve can
determine if it's SRU worthy

https://code.launchpad.net/~gleichsnerd/ubuntu/precise/mountall/fix-for-805509/+merge/100305
 - patch was fine, needed a little more information before sponsoring though

The prompt for installing MP3 playback support dialogue box does not fit
in a 1024x600 display - 962860 <https://launchpad.net/bugs/962860>
 - No upstream patch acceptance (Ubuntu One) nor UIFe paperwork,
unsubscribed -sponsors

gnome-desktop-item-edit should be in a new package - Bug #97529
 - Needs coordination with Debian, affects seeded packages, mentioned
asking for SRU approval once it's sorted in 12.10, unsubscribed -sponsors

https://code.launchpad.net/~roadmr/ubuntu/precise/casper/973794/+merge/100893
 - had stgraber look at it and he already fixed the issue
 - discovered that the importer "had fun" ala reverting and recommitting
with the casper UDD branch and filed bug 985465

Sync kernel-package 12.036+nmu2 (universe) from Debian testing (main) -
Bug #975392
 - was already sync'd, marked fix released

Wanda the fish is a mute! - Bug #433631
 - potential lucid SRU, not sure if precise is affected, linked Debian
bug, asked patch writer to research, unsubscribed -sponsors

Queue is down to 45

--
Micah Gersten
Ubuntu Security Team

-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: third test rebuild of precise pangolin

[Micah Gersten]

On 04/03/2012 10:12 AM, Martin Pitt wrote:
> Colin Watson [2012-04-03 16:08 +0200]:
>> aisleriot (i386, amd64, armhf):
>> libical (i386, armhf):
> These two are in progress in the desktop team ATM.
>
>> heartbeat (i386, amd64, armhf):
>>   Needs to move to single  includes rather than .
> Actually, we'll fix our "revert single include requirement" patch
> harder in glib2.0, to also avoid this kind of FTBFS in universe. This
> will fix some 20 FTBFS.
>
> Martin
>
Won't reverting the single header include just cause other glib related
include failures for moving headers?  I guess it might possibly be less
than the current number though.

Micah

-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: [Bug 971000] Re: Sync wireshark 1.6.6-1 (universe) from Debian testing (main)

[Micah Gersten]

On 04/02/2012 01:00 AM, Fabrice Coutadeur wrote:
> Sponsoring by parts so that each contributors get credit for hos work.
>
> @Evan: is a new version is bug-fixing only , please mention it in the
> sync request, bringing some proof of it.
>
> anyway, thanks for your work!
>

While I like this in theory, in practice it creates more build churn
than necessary,  Even on the new panda arm* builders Wireshark takes
almost 2 hours.  While it's true that superseded builds are skipped,
that's only if they haven't started yet.  You could have the same result
of giving credit by merging in bzr in the UDD branch and using the
--author flag to give credit to each person.  Then, once all the changes
are merged in, you could do one upload.  These "credited" contributions
can be taken into account for dev applications as well.

Thanks,
Micah

-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: Every Ubuntu developer is a Unity developer?

[Micah Gersten]

You're an explicit member of the team since 2010-06-14, I have no idea why.
Micah

On 03/18/2012 07:24 PM, Scott Kitterman wrote:
> Could whoever is administrator for the appropriate teams arrange it so that 
> ubuntu-dev don't get mails like this?
>
> Thanks,
>
> Scott K
>
> --  Forwarded Message  --
>
> Subject: Questions and Suggestions on Unity as of last  Beta
> Date: Sunday, March 18, 2012, 08:28:08 PM
> From: Buyongo Phiri 
> To: Scott Kitterman 
>
> Hello folks,
>
> These are my comments and questions on dash and launcher behaviour,
> please let me know if I am in the right place and if everything makes
> sense and whatnot.
>
> When you click on the ubuntu(dash-invoker button) you are presented with
> recent apps, isnt it redundant to have recent apps on the apps lens*?
> Also shouldnt the apps lens categorize applications instead of an
> alphabetically listing all of them? Its a real eye-sore moving around
> seaching for power settings or something and even worse when you dont
> know* or remember the app name.
> (*Recent apps-maybe it would be better to have two rows by default
> instead of having a user click to see the second row?? )
>
> I think something like so would be visually more agreeable...
>
> App dash
>
> [Recent Apps - *Redundant because you see the same information when dash
> launches] Maybe it should go?
>
> Label - Accessories Filter
> All Apps under this category[Jump to
> section*?]
>
> Label - Accesibility
> All Apps under this category
>
> Label - Customisation
> All Apps under this category
>
> Also maybe a colour coded overlay for the different app sections or all
> apps in a certain category will have a certain colour when hovered
> over*?
>
> My last question is for the launcher, would it be easier to have the
> launcher pin running apps to the top like so.
>
> Dash invoker button
> [running apps]
> {spacer of some sort for visual whitespace}
> Favourites
> Trash
>
> When I have my laucher full of apps that are running and it mixes with
> my favourites it can be quite cluttered and there isnt a real easy way
> to scroll around. For example on my computer it is as follows.
>
> Dash invoker
> Firefox
> Software center
> Text editor
> Home folder
> Terminal
> Miro
> Abiword
> Eclipse
> etc*
> Running app
> Running app
> Running app thats in my launcher
>
> Maybe it would work better if all running apps where at the top then if
> an app is pinned to the launcher and running it simply moves up the
> "food chain" when not running it moves back to its launcher slot.And to
> make sure users can see the distinction, the area covered by running
> apps should have a slightly different colour.


-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: [RFC] Drop Non-smp PowerPC Kernel Flavor

[Micah Gersten]

On 03/14/2012 12:00 PM, Colin Watson wrote:
> On Wed, Mar 14, 2012 at 09:52:01AM -0700, Leann Ogasawara wrote:
>> The Ubuntu Kernel Team has been evaluating some of the current
>> maintenance burdens for the upcoming Precise Pangolin 12.04 LTS release.
>> One area which would reduce the maintenance costs would be to drop the
>> non-smp PowerPC kernel flavor.  There are currently three PowerPC
>> flavors:
> Making the associated installer changes shouldn't be a big deal, but I
> suggest you ask the Xubuntu and Lubuntu communities about this since a
> good proportion of powerpc users are there.
>
Xubuntu stopped producing PowerPC images due to a lack of testers.  If
there's interest in these, and people committed to testing, they could
be reinstated.

Thanks,
Micah

-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: [RFC] Drop Non-smp PowerPC Kernel Flavor

[Micah Gersten]

On 03/14/2012 11:52 AM, Leann Ogasawara wrote:
> Hi All,
>
> The Ubuntu Kernel Team has been evaluating some of the current
> maintenance burdens for the upcoming Precise Pangolin 12.04 LTS release.
> One area which would reduce the maintenance costs would be to drop the
> non-smp PowerPC kernel flavor.  There are currently three PowerPC
> flavors:
>
>  * non-smp (linux-image-powerpc)
>  * smp (linux-image-powerpc-smp)
>  * smp-64 (linux-image-powerpc64-smp)
>
> Even though PowerPC is a community maintained port [1], the PowerPC
> kernels are still generated along side the officially supported distro
> kernels.  Taking that into consideration, every PowerPC flavor takes
> ~2hrs to build, ie. ~6hrs for all three flavors.  Given the number of
> official builds and test builds that are performed over the life of the
> LTS, this equates to a significant amount of time.
>
> We would thus like to propose dropping the non-smp PowerPC kernel
> flavor.  Doing so would also require the installer to be updated, hence
> CC'ing Colin Watson.  We'd like to drop this as soon as possible, in
> time for Beta-2 would be ideal.
>
> Thoughts?
>
> Thanks,
> Leann Ogasawara
>
> [1] 
> https://lists.ubuntu.com/archives/ubuntu-announce/2007-February/98.html
>
>
What's the impact on supported PowerPC hardware?

Micah

-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: Is there any issue accepting several versions at once (Re: [ubuntu/precise] gnome-control-center 1:3.3.90-0ubuntu3 (Rejected))

[Micah Gersten]

On 02/27/2012 10:19 AM, Scott Kitterman wrote:
>
> Sebastien Bacher  wrote:
>
>> Le 25/02/2012 17:15, Ubuntu Installer a écrit :
>>> Rejected:
>>> Rejected by archive administrator.
>>>
>>> gnome-control-center (1:3.3.90-0ubuntu3) precise; urgency=low
>>>
>>>* debian/patches/62_update_translations_template.patch:
>>>  - update POTFILES.in with the ubuntu specific sources for
>> translation
>> Hey,
>>
>> Dunno who rejected that upload so comment on the list, is there an
>> issue 
>> to accept several versions at once? What happened there is that
>> somebody 
>> else uploaded a new revision while mine was in the queue, so I guess 
>> whoever dealt with those accepted the new one and rejected the previous
>>
>> one, which is fine but:
>>
>> - the change I did was never advertised on -changes (which means people
>>
>> who use the list to track what is changing get confused)
>> - if there is any bug that should have been closed with that upload if 
>> wouldn't have been closed
>> - the uploader gets a rejection mail with explanation which is
>> confusing
>>
>> We could say that uploaders should check the unapproved queue before 
>> uploading a new revision of something in the queue and use -v, but 
>> wouldn't it be simpler to just accept both versions and let launchpad busy 
>> and
>> deal with the builds?
> I think that was me.
>
> IIRC the buildd's were busy and it seemed wasteful. The lower revision would 
> probably end up failed to upload. 
>
> While I don't know of specific bugs, I think inviting Soyuz to get in a race 
> with itself is generally not prudent.
>
> Scott K
>
If it's the same source package, if the later one is accepted first, the
earlier one will fail to build for superseded source (i.e. never
start).  Still, I think in this case either both should be allowed in
descending order, or both rejected so that someone can do a proper
upload showing all the changes.  There's also the worry that changes can
be missed in cases like this as like what happened with apt-cacher-ng
[1][2][3]  It seems like rejecting both with a message telling the
uploaders to talk to each other seems most prudent unless it's a
critical fix.

Thanks,
Micah

[1]
https://lists.ubuntu.com/archives/precise-changes/2012-February/010766.html
[2]
https://lists.ubuntu.com/archives/precise-changes/2012-February/010772.html
[3]
https://lists.ubuntu.com/archives/precise-changes/2012-February/010805.html


-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: [ubuntu/precise] lzma 9.22-2ubuntu1 (Accepted)

[Micah Gersten]

On 02/07/2012 07:00 PM, Leo Iannacone wrote:

lzma (9.22-2ubuntu1) precise; urgency=low

   * Merge from debian unstable (LP: #924044).  Remaining changes:
 - make lzma Priority: required and Section: base since
   dpkg Pre-Depends on it.

lzma (9.22-2) unstable; urgency=low

   * Upload to unstable.
   * Previous upload removed lzma-source. (Closes: #651796)
   * Prevent /dev/null removal while testing a file. (Closes: #550543)

lzma (9.22-1) experimental; urgency=low

   [ Mohammed Adnène Trojette ]
   * New upstream release (Closes: #460501, #518365)
  + LZMA SDK is placed in the public domain since 4.62.
   * Update debian/patches/02_lzmp.diff.
   * Switch packaging under the terms of the BSD license.
   * Switch to dpkg-source 3.0 (quilt) format
  + debian/control: Build-Depends
 - drop quilt.
 - bump debhelper dependency to 8.0.0.
   * Bump Standards-Version to 3.9.2
   * Drop lzma-source package. It doesn't work with current kernels and
 SquashFS XZ is part of the standard kernel now. Patch courtesy of
 Jonathan Nieder. (Closes: #470893, #553707, #466582)
   * Update file list in lzma-dev. (Closes: #614417)
   * Fix and improve descriptions. (Closes: #535776, #540469)
   * Add deb-lzma script to convert a deb package to LZMA format. Script
 courtesy of Roger Millan. (Closes: #536275)
   * Add Jonathan Nieder as comaintainer.

   [ Jonathan Nieder ]
   * Bump debhelper compatibility to 7.
   * Manage lzma, unlzma, and lzcat through the alternatives system.
 Conflicts: xz-lzma (<<  5.1.1alpha+20110809-2). (Closes: #547802)

Date: Tue, 31 Jan 2012 01:32:49 +0100
Changed-By: Leo Iannacone
Maintainer: Ubuntu Developers
Signed-By: Alessio Treglia
https://launchpad.net/ubuntu/precise/+source/lzma/9.22-2ubuntu1


Current dpkg on precise:
Package: dpkg
Essential: yes
Priority: required
Section: admin
Installed-Size: 5931
Maintainer: Ubuntu Developers 
Original-Maintainer: Dpkg Developers 
Architecture: amd64
Version: 1.16.1.2ubuntu5
Pre-Depends: libbz2-1.0, libc6 (>= 2.11), libselinux1 (>= 1.32), zlib1g 
(>= 1:1.1.4), coreutils (>= 5.93-1), tar (>= 1.23), xz-utils

Suggests: apt
Breaks: apt (<< 0.7.7), aptitude (<< 0.4.7-1), dpkg-dev (<< 1.15.8), 
libdpkg-perl (<< 1.15.8), pinfo (<< 0.6.9-3.1), tkinfo (<< 2.8-3.1)


It seems like this could've been a sync.

Thanks,
Micah


--
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Fwd: Team maintaining miniupnp: a set of 4 packages to manage IGD protocols

[Micah Gersten]

If anyone has any applications they like/watch depending on these 4
packages, this would be a great way to insure they're up to date and
help Debian at the same time.

Reverse-Build-Depends
=
* bitcoin   (for libminiupnpc-dev)
* eiskaltdcpp   (for libminiupnpc-dev)
* megaglest (for libminiupnpc-dev)
* transmission  (for libminiupnpc-dev, libnatpmp-dev)
* vino  (for libminiupnpc-dev)
* warzone2100   (for libminiupnpc-dev)



 Original Message 
Subject:Team maintaining miniupnp: a set of 4 packages to manage IGD
protocols
Resent-Date:Fri, 3 Feb 2012 01:36:11 + (UTC)
Resent-From:debian-de...@lists.debian.org
Date:   Fri, 03 Feb 2012 09:18:11 +0800
From:   Thomas Goirand 
Organization:   Debian
To: Debian Developers 



Hi,

I'm currently maintaining alone the following source packages:
libnatpmp, minissdpd, miniupnpc and miniupnpd

For that last one, I've just sent an ITP, since it finally becomes
possible to build it in Debian (and the packaging is already done,
sitting in my public_git on Alioth). MiniUPnPd is already used in many
embedded devices like OpenWRT, and in some major ISP ADSL boxes (I wont
write names, but for example, the 2nd and 3rd largest ISP in France runs
it).

The miniupnpc is a nice library that may be use by many games, and is
already used by some software in the archive, like warzone2100,
transmission, and bitcoind. Both minissdpd and miniupnpc are quite high
already in popcon, with more than 8000 users, which also is pushing me
to ask for other sets of eyes to look into my packaging. The miniupnpc
client library would need a transition to reach testing the correct way
(because of a tiny change in the API, the package is already in
Experimental), and I have no experience with that, help would be
appreciated.

I found that team maintaining is cool, and I'd like to know if others
would like to join my effort to keep all the MiniUPnP software into
shape in Debian. It wouldn't be much work, just the usual work to keep
the packages updated with what upstream releases.

Note that upstream (Thomas Bernard) is a very good friend of mine, and
is both a cool guy and very responsive.

So if you wish to join the maintenance effort for MiniUPnPd, please get
in touch, and we'll build a (new) Alioth project.

Cheers,

Thomas Goirand (zigo)



-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Minutes from the Developer Membership Board meeting, 2012-01-16

[Micah Gersten]

== Meeting summary ==


* Present: micahg (chair), Laney, tumbleweed, geser, stgraber


 *Review of previous action items
  *cody-somerville to write some documentation on how to endorse
someone  (micahg, 14:08:02)
  - Deferred to next meeting
 *bdrung to talk to the TB about harmonising DMB members' expiration
dates for easier restaffing  (micahg, 14:09:18)
   Done - ''LINK:''
https://lists.ubuntu.com/archives/technical-board/2012-January/001161.html  
(micahg, 14:09:27)

 *Review any packageset descriptions that have been received (micahg)
  - Deferred

 *DMB members terms expiring
laney and geser's terms for the DMB are ending 2012-02-13  (micahg,
14:11:35)
''ACTION:'' micahg to E-Mail TB to extend Laney's term 1yr (as the
initial date was an error)  (micahg, 14:15:49)
''ACTION:'' tumbleweed to run the election to fill geser's seat 
(micahg, 14:17:30)
''ACTION:'' tumbleweed to send mail requesting nominations for the open
DMB seat  (micahg, 14:18:02)


 *select chair for next meeting
stgraber to chair next meeting  (micahg, 14:21:41)



Full Meeting Log here:
http://ubottu.com/meetingology/logs/ubuntu-meeting/2012/ubuntu-meeting.2012-01-16-14.07.moin.txt




signature.asc
Description: OpenPGP digital signature
-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Call For Testing: Lucid and Maverick Firefox users (or willing to install Lucid or Maverick in a VM)

[Micah Gersten]

We need Lucid and Maverick users to test our latest Firefox Upgrade!

*Background:*
The upstream Mozilla Firefox web browser has moved to a rapid release
cycle. New Firefox versions are being released every six weeks and
contain new features and security enhancements. Until now, Ubuntu 10.04
LTS and Ubuntu 10.10 have been getting 3.6 point releases of Firefox. As
such, users have not been benefiting from new features, support for new
web technologies, security enhancements, and performance improvements.
Firefox 3.6 will be reaching its end of life soon, so we need to migrate
users to the rapid release so that they will continue to receive
security updates in a timely fashion. See [1] for more information.

Before releasing these updates to the public, we need testing of the
following packages:

  * firefox
  * xul-ext-webfav
  * xul-ext-mozvoikko
  * gecko-mediaplayer
  * moonlight-plugin-core

These updates are currently in lucid-proposed and maverick-proposed. 
Please keep in mind, that lucid-proposed or maverick-proposed might get
you a lot of other extra packages as well.

We need people running Lucid or Maverick in bare metal or a virtual
machine. If you are willing to help, here's what you can do:

First, enable the Lucid or Maverick proposed repository [2]. Then, you
can either run update-manager or 'sudo apt-get update && sudo apt-get
dist-upgrade'.

If you find a bug in these packages, please file a new bug with the
issue and if it's a regression, please comment in bug 904594 [3].

Feel free to subscribe to bug 904594 [3] to follow the progress, but be
forewarned that you will probably get a lot of E-Mail from it.

Please note, packages need to be tested to migrate to lucid-updates or
maverick-updates.

There is a short functional test plan after the links.  These are for
people that would like to do one time testing rather than just running
the proposed packages for their normal workflow.

Thanks to everyone in advance,
Micah

[1]
https://lists.ubuntu.com/archives/ubuntu-security-announce/2012-January/001544.html

[2] https://wiki.ubuntu.com/Testing/EnableProposed

[3] https://bugs.launchpad.net/bugs/904594

Test Plan (for functional testing):

 1. Create a new profile (firefox -P) (optional except for certificate test)
 2. test save an image, does dialog appear et al?
 3. test bookmarks: can you drag/drop bookmarks (in manager and in UI -
e.g. from toolbar to menu et al)?
 4. test password manager:
  * are passwords properly pre-filled when previously remembered?
  * are credentials of new sites properly remembered as well (test
in same browser session and with browser restarted)
 5. test plugins (flash, java)
 6. test javascript: use AJAX sites like: new mail.yahoo.com, gmail.com,
maps.google.com et al.
 7. test https site (https://www.launchpad.net)
 8. test certificate support:
  * ensure that https://www.cacert.org/index.php?id=1 gives you a
certificate warning (e.g. by removing previously imported certificate
from trust db in Preferences -> Advanced -> Encryption -> View Certificates)
  * open http://www.cacert.org/certs/root.crt ... are you asked to
import? if so do import and select "Trust this CA to identify websites"
  * after that visiting https://www.cacert.org/index.php?id=1 should
not give you a warning anymore
 9. test gnome support:
  * Use Image as Background
  * Change Preferred Application (Mail-- in Gnome, set in
System/Preferences/Preferred Applications)

-- 
Micah Gersten
Ubuntu Security Team


-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: xz-compression related upload failure

[Micah Gersten]

On 12/19/2011 02:48 PM, Micah Gersten wrote:
> On 12/19/2011 02:43 PM, Stefan Potyra wrote:
>> Hi,
>>
>> just found out about trigger-rally-data failing to upload:
>>
>> <https://launchpadlibrarian.net/87895494/upload_3177594_log.txt>
>>
>> As far as I'm aware, xz compression was supported within dpkg prior to Lucid,
>> so I presume that the upgrade path from LTS to LTS is fine.
>>
>> Am I missing something here?
>>
>> Cheers and TIA,
>> Stefan.
>>
> No, Lucid has dpkg 1.15.5.6ubuntu4 and this feature was added in dpkg
> 1.15.6, so a Pre-Depends is needed for LTS to LTS upgrades.
>
> Thanks,
> Micah
>
>
You may be thinking of the xz source compression which was available in
Lucid's dpkg.
-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: xz-compression related upload failure

[Micah Gersten]

On 12/19/2011 02:43 PM, Stefan Potyra wrote:
> Hi,
>
> just found out about trigger-rally-data failing to upload:
>
> 
>
> As far as I'm aware, xz compression was supported within dpkg prior to Lucid,
> so I presume that the upgrade path from LTS to LTS is fine.
>
> Am I missing something here?
>
> Cheers and TIA,
> Stefan.
>
No, Lucid has dpkg 1.15.5.6ubuntu4 and this feature was added in dpkg
1.15.6, so a Pre-Depends is needed for LTS to LTS upgrades.

Thanks,
Micah
-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Patch Pilot report 2011-12-05

[Micah Gersten]

31 items in queue at the start of my shift

Bug #900457 - Sync tracker 0.12.8-1 (universe) from Debian unstable (main)
 - sync ACKd

Bug #900351 - Please merge libparse-http-useragent-perl 0.33-1
(universe) from Debian unstable
 - debdiff was fine, test built, uploaded

Review Seamonkey 2.5 branch merge from Joe Lesko (not in queue)
 - needed some cleanup, working with him on it

Review bug 900596/Merge
lp:~nataliabidart/ubuntu/precise/magicicada/magicicada-0.4.1 into
lp:ubuntu/magicicada
 - branch had some issues with the changelog and possible accidental
changes, marked as Incomplete/Needs Fixing

Reviewed bug 900421/900565 about multiarch conversions, but had a
question about whether or not we should be pushing Pre-Depends:
${misc:Pre-Depends} as opposed to Pre-Depends: multiarch-support, the
former is on the Debian Wiki conversion guide, the latter is less
invasive of a packaging change which might appeal to some maintainers, I
believe the answer is we should be doing as the wiki suggests and if
maintainers complain, explain why the change is better (i.e.
multiarch-support Pre-Depends controlled from a single location vs
thousands of source packages), but I wanted to be sure before sponsoring
these debdiffs

Review Bug #839745 - chemtool translation not working
 - missing minimal debdiffs, requested updated versions, unsubscribed
sponsors

Reviewed Merge lp:~tkluck/ubuntu/oneiric/goocanvas/v2 into
lp:ubuntu/goocanvas
 - lots of issues, requested fixing and suggested the updater to contact
the Debian maintainer since the package hasn't been touched in Debian in
18 months and has seen 3 upstream releases this year
 - updater responded, he's working to get a new source into Debian so we
can keep GTK2/GTK3 versions of goocanvas if necessary

looked at Bug #899315 - ebtables crashed with SIGSEGV in
ebt_initialize_entry()
 - wasn't happy with the patch, requested patch writer to actually fix
the -as-needed issue and not work around it, milestoned for alpha2 since
it's a regression with a seemingly easy fix, tagged regression-release,
subscribed to bug to keep an eye on it

28 items at the end of my shift

-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: Using webkit 1.8 for the LTS(?)

[Micah Gersten]

On 11/30/2011 04:52 PM, Micah Gersten wrote:
> On 11/30/2011 04:41 PM, Sebastian Heinlein wrote:
>> Am Dienstag, den 29.11.2011, 20:27 -0500 schrieb Rodney Dawes:
>>> On Tue, 2011-11-29 at 19:55 +0100, Sebastien Bacher wrote:
>>>> What is your take on using webkit 1.8? Is that choice good for other 
>>>> teams? Is there any issue or concern you have about updating?
>>> As an aside, but also a valid issue, regardless of the version we go
>>> with... are there any sort of plans on getting Flash working inside the
>>> GTK3 version of webkit, out of the box?
>> "Thanks to the multiprocess architecture, WebKit2GTK+ solves the problem
>> of using flash (or any other plugin using GTK+2) with GTK+3. The UI
>> process depends unconditonally on GTK+3 and the plugin process is always
>> built with GTK+2. And of course, flash will never crash or block your
>> web browser. Plugins are broken in WebKitGTK+ 1.7.1 due to a bug that
>> has already been fixed, so in order to try it out you need to either
>> wait until 1.7.2 is released or build WebKit from current git master."
>>
>> http://blogs.igalia.com/carlosgc/2011/11/04/webkit2-gtk-minibrowser-ported-to-gtk-api/
>>
>
> Right, but I thought WebKit2GTK+ was still going to be in beta for 1.8
> which means that we probably wouldn't use it and it wouldn't solve any
> of our problems.
>
> Thanks,
> Micah
>
Sorry, I have to apologize for the tone of this E-Mail. Sebastian, thank
you for that information.
Micah
-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: Using webkit 1.8 for the LTS(?)

[Micah Gersten]

On 11/30/2011 04:41 PM, Sebastian Heinlein wrote:
> Am Dienstag, den 29.11.2011, 20:27 -0500 schrieb Rodney Dawes:
>> On Tue, 2011-11-29 at 19:55 +0100, Sebastien Bacher wrote:
>>> What is your take on using webkit 1.8? Is that choice good for other 
>>> teams? Is there any issue or concern you have about updating?
>> As an aside, but also a valid issue, regardless of the version we go
>> with... are there any sort of plans on getting Flash working inside the
>> GTK3 version of webkit, out of the box?
> "Thanks to the multiprocess architecture, WebKit2GTK+ solves the problem
> of using flash (or any other plugin using GTK+2) with GTK+3. The UI
> process depends unconditonally on GTK+3 and the plugin process is always
> built with GTK+2. And of course, flash will never crash or block your
> web browser. Plugins are broken in WebKitGTK+ 1.7.1 due to a bug that
> has already been fixed, so in order to try it out you need to either
> wait until 1.7.2 is released or build WebKit from current git master."
>
> http://blogs.igalia.com/carlosgc/2011/11/04/webkit2-gtk-minibrowser-ported-to-gtk-api/
>

Right, but I thought WebKit2GTK+ was still going to be in beta for 1.8
which means that we probably wouldn't use it and it wouldn't solve any
of our problems.

Thanks,
Micah
-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: Using webkit 1.8 for the LTS(?)

[Micah Gersten]

On 11/29/2011 12:55 PM, Sebastien Bacher wrote:
> Hi everybody,
>
> So following-up on the email I just sent and trying to improve how we
> decide on things that might have an impact on others teams I would
> like to discuss what version of webkit we will use for the LTS.
>
> In Oneiric we stayed on 1.4 because we were unsure that 1.6 would be
> on time, that leaded to some issues with GNOME (which started using
> the new version). We discussed the topic with upstream since and they
> said they follow the GNOME schedule nowadays and the project and team
> is active enough that there should be no issue for them to stay on track.
>
> We discussed a bit, at UDS, what version to track for Precise and the
> consensus seemed to be that we would benefit to have the most recent
> version and should go for 1.8 (which will turn stable in march). I
> still need to confirm with upstream that they will keep supporting
> gtk2 as a build time option for that serie (I pinged them today but
> didn't get a reply yet).
>
> What is your take on using webkit 1.8? Is that choice good for other
> teams? Is there any issue or concern you have about updating?
>
> -- 
> Sebastien Bacher
>
This should be fine as long as 1.8 has GTK2 support still.  With my
security hat on, as long as we have ABI compatibility (at least as much
as 1.6 offered) and GTK2 support, 1.8 would be a much better base for
the LTS over 1.6 since we're 6 months closer to trunk out of the gate.

Thanks,
Micah



-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: Checklist of package changes for new distribution?

[Micah Gersten]

On 11/07/2011 11:55 AM, Colin Watson wrote:
> On Mon, Nov 07, 2011 at 12:35:36PM -0500, Andrew Starr-Bochicchio wrote:
>> This should no longer be needed in future releases of bzr-builddeb. I
>> committed a change to use python-distro-info instead of having to
>> manually fix this every six months. We should really try to use
>> distro-info where possible.
> Some packages can't though - for example debootstrap needs to be
> runnable in contexts where distro-info isn't available (from the
> installer, and from other distributions).
>
It could be fixed to just require a no change rebuild against the newer
distro-info rather than hardcoding.  I was thinking of fixing that if
more people than I believe it's worthwhile.

Thanks,
MIcah

-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: [ubuntu/precise] xine-lib 1.1.19-3.1ubuntu1 (Accepted)

[Micah Gersten]

On 10/30/2011 05:49 PM, Micah Gersten wrote:
> On 10/30/2011 05:35 PM, Reinhard Tartler wrote:
>> xine-lib (1.1.19-3.1ubuntu1) precise; urgency=low
>>
>>   * merge from debian, remaining changes:
>> - Because the following libraries are only in universe,
>>   build against internal copies of:
>>   - libdvdnav, libdvdread, libfaad, libvcdinfo-dev
>> - change order of the alternate dependencies libxine-plugins and
>>   libxine1-misc-plugins. The former would drag in libxine1-ffmpeg
>>   via recommends on the live cd.
>>   * reenable xineplug_decode_image.so
>> - use libmagickwand-dev instead of graphicsmagick-libmagick-dev-compat
>>   as the former is found in ubuntu/main.
>>
>> xine-lib (1.1.19-3.1) unstable; urgency=low
>>
>>   * Non-maintainer upload.
>>   * Add patch from Reinhard Tartler to fix FTBFS with libav 0.7.  Closes:
>> #628197.
>>   * Add patch from Loic Dachary to remove pvr from the plugins now that v4l
>> is gone. Enable v4l on linux instead of on !linux.  Closes: #623595.
>>
>> xine-lib (1.1.19-3) unstable; urgency=low
>>
>>   * add missing #include to avoid FTBFS,
>> Closes: #610635
>>
>> Date: Sat, 29 Oct 2011 18:58:50 +0200
>> Changed-By: Reinhard Tartler 
>> Maintainer: Ubuntu Core Developers 
>> https://launchpad.net/ubuntu/precise/+source/xine-lib/1.1.19-3.1ubuntu1
>>
>
> This is troubling, here's the last merge changelog entry:
> xine-lib (1.1.19-2ubuntu1) natty; urgency=low
>
>   * merge from debian, remaining changes:
> - remove build-dependency on libvcdinfo-dev, fixes FTBFS.
> - don't build against system libdvdnav, libdvdread, both in universe
> - build the faad plugin against the internal copy of libfaad
> - change order of the alternate dependencies libxine-plugins and
>   libxine1-misc-plugins. The former would drag in libxine1-ffmpeg
>   via recommends on the live cd.
>   * remove graphicsmagick-libmagick-dev-compat, not in main
>
>
> Before, we were only using one internal library and building one
> plugin from it.  Now we're building against 4 internal libraries. 
> This doesn't seem like a good idea for the LTS as the security team
> will most likely have to support those embedded libraries for 5
> years.  Is there a need for this change?  Also, the only rdepends of
> xine-lib in main are kaffeine and kde-runtime.
> @kubuntu-devel
> Do we need this other functionality?  If so, can we please get MIRs
> for those libraries?
>
> Thanks,
> Micah
>
I have to apologize.  As Colin pointed out to me in #ubuntu-devel,
nothing has actually changes between the natty and precise packages in
terms of the diff from Debian (i.e. changing which internal libraries
are built against).  So, thank you Reinhard for making the current state
clearer in the changelog :).  However, these should still probably be
examined for the LTS if we should be using these internal libs, MIR
them, or possibly drop them from the package.

Apologies for my hastiness,
Micah
-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: [ubuntu/precise] xine-lib 1.1.19-3.1ubuntu1 (Accepted)

[Micah Gersten]

On 10/30/2011 05:35 PM, Reinhard Tartler wrote:
> xine-lib (1.1.19-3.1ubuntu1) precise; urgency=low
>
>   * merge from debian, remaining changes:
> - Because the following libraries are only in universe,
>   build against internal copies of:
>   - libdvdnav, libdvdread, libfaad, libvcdinfo-dev
> - change order of the alternate dependencies libxine-plugins and
>   libxine1-misc-plugins. The former would drag in libxine1-ffmpeg
>   via recommends on the live cd.
>   * reenable xineplug_decode_image.so
> - use libmagickwand-dev instead of graphicsmagick-libmagick-dev-compat
>   as the former is found in ubuntu/main.
>
> xine-lib (1.1.19-3.1) unstable; urgency=low
>
>   * Non-maintainer upload.
>   * Add patch from Reinhard Tartler to fix FTBFS with libav 0.7.  Closes:
> #628197.
>   * Add patch from Loic Dachary to remove pvr from the plugins now that v4l
> is gone. Enable v4l on linux instead of on !linux.  Closes: #623595.
>
> xine-lib (1.1.19-3) unstable; urgency=low
>
>   * add missing #include to avoid FTBFS,
> Closes: #610635
>
> Date: Sat, 29 Oct 2011 18:58:50 +0200
> Changed-By: Reinhard Tartler 
> Maintainer: Ubuntu Core Developers 
> https://launchpad.net/ubuntu/precise/+source/xine-lib/1.1.19-3.1ubuntu1
>

This is troubling, here's the last merge changelog entry:

xine-lib (1.1.19-2ubuntu1) natty; urgency=low

  * merge from debian, remaining changes:
- remove build-dependency on libvcdinfo-dev, fixes FTBFS.
- don't build against system libdvdnav, libdvdread, both in universe
- build the faad plugin against the internal copy of libfaad
- change order of the alternate dependencies libxine-plugins and
  libxine1-misc-plugins. The former would drag in libxine1-ffmpeg
  via recommends on the live cd.
  * remove graphicsmagick-libmagick-dev-compat, not in main



Before, we were only using one internal library and building one plugin
from it.  Now we're building against 4 internal libraries.  This doesn't
seem like a good idea for the LTS as the security team will most likely
have to support those embedded libraries for 5 years.  Is there a need
for this change?  Also, the only rdepends of xine-lib in main are
kaffeine and kde-runtime.
@kubuntu-devel
Do we need this other functionality?  If so, can we please get MIRs for
those libraries?

Thanks,
Micah
-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: swig2.0 transition and removal of swig1.3 for precise?

[Micah Gersten]

On 10/28/2011 01:24 AM, Micah Gersten wrote:
> swig1.3 has been removed from Debian testing and unstable as it has been
> superseded by swig2.0.  Does anyone have an objection to me setting up a
> tracker to drive the transition to swig2.0 and the eventual removal of
> swig1.3 from precise?
>
> Thanks,
> Micah
>
>
Just discussed with doko on #ubuntu-devel, there are only 2 packages
with a real dependency on swig1.3, so I'll fix those and file for
removal, sorry for the noise.

Micah

-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

swig2.0 transition and removal of swig1.3 for precise?

[Micah Gersten]

swig1.3 has been removed from Debian testing and unstable as it has been
superseded by swig2.0.  Does anyone have an objection to me setting up a
tracker to drive the transition to swig2.0 and the eventual removal of
swig1.3 from precise?

Thanks,
Micah


-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: Patch Pilot Report 2011-10-25

[Micah Gersten]

On 10/25/2011 04:46 PM, Benjamin Drung wrote:
> Am Dienstag, den 25.10.2011, 12:47 -0500 schrieb Micah Gersten:
>> On 10/25/2011 07:19 AM, James Page wrote:
>>> https://bugs.launchpad.net/ubuntu/+source/apcalc/+bug/880074
>>> Build OK - synced from Debian testing.
>>
>> Until we can sponsor syncs through the LP API [1], and as long as
>> there's not an immediate need for the sync, we should probably just
>> subscribe ubuntu-archive, unsubcribe ubuntu-sponsors, and set to
>> Confirmed once a sync is validated so that the requester can get proper
>> credit for it.
>
> You can use sponsor-patch in oneiric, which does this job for you.

I thought sponsor-patch was for patches/merges, we're talking about
syncs here.

Thanks,
Micah

-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: data.tar.xz support added to Launchpad

[Micah Gersten]

On 10/25/2011 03:15 PM, Barry Warsaw wrote:
> On Aug 26, 2011, at 10:32 PM, Colin Watson wrote:
>
>> It should now be possible to use xz compression for .deb packages
>> uploaded to Ubuntu oneiric (using 'dh_builddeb -- -Zxz').  In order to
>> do so, you must include this field in the relevant binary packages:
>>
>>  Pre-Depends: dpkg (>= 1.15.6)
> I just ran into this when I merged testing's version of m2crypto, which had
> switched to xz compression.  The merge was tricky and I missed this tidbit in
> the Debian packaging, but I did do a local sbuild for precise before uploaded,
> and it succeeded without the Pre-Depends.
>
> However, when the buildd got to that point, it failed:
>
> https://launchpadlibrarian.net/83677349/buildlog_ubuntu-precise-amd64.m2crypto_0.21.1-2ubuntu1_BUILDING.txt.gz
>
> I need to try it again on pbuilder to see what happens there.  Of course, it's
> easy enough to add the Pre-Depends, but now I'm gunshy and don't trust my
> sbuild environment, so I'm building it in a PPA first.  Unfortunately, that's
> scheduled for *2 days* from now (!).  Yeah, I'll try to get it re-scored, but
> that's beside the point.
>
> Any idea why it succeeded in sbuild, and do you have any other suggestions for
> testing such package builds locally before uploading?
>
> -Barry
>
>
It's a check on upload and not during the build would be my guess. 
Maybe we should add a lintian warning/error if it uses .xz debs w/out
the pre-depends.

Micah
-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: Patch Pilot Report 2011-10-25

[Micah Gersten]

On 10/25/2011 07:19 AM, James Page wrote:
> https://bugs.launchpad.net/ubuntu/+source/apcalc/+bug/880074
> Build OK - synced from Debian testing.

Until we can sponsor syncs through the LP API [1], and as long as
there's not an immediate need for the sync, we should probably just
subscribe ubuntu-archive, unsubcribe ubuntu-sponsors, and set to
Confirmed once a sync is validated so that the requester can get proper
credit for it.  If there is an immediate need, I'd suggest asking an
archive admin in #ubuntu-devel to do the sync.  Of course, world burning
need would be at your discretion :)

Thanks,
Micah


[1] https://bugs.launchpad.net/bugs/827555

-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: [ubuntu/precise] aptsh 0.0.7+nmu2ubuntu1 (Accepted)

[Micah Gersten]

Fixed Top Post...
On 10/25/2011 11:26 AM, Steve Stalcup wrote:
>
> On Oct 25, 2011, at 1:32 AM, Micah Gersten  <mailto:mic...@ubuntu.com>> wrote:
>
>> On 10/25/2011 02:25 AM, Nicolas Valcarcel Scerpella wrote:
>>> aptsh (0.0.7+nmu2ubuntu1) precise; urgency=low
>>>
>>>   * Merge from debian unstable.  Remaining changes:
>>> - debian/control: change Build-Depends from libreadline5-dev to
>>>   libreadline-dev for readline transition.
>>>
>>> aptsh (0.0.7+nmu2) unstable; urgency=low
>>>
>>>   * Non-maintainer upload.
>>>   * debian/control: Build-Depend on libreadline-gplv2-dev instead of
>>> libreadline5-dev. (Closes: #553726)
>>>   * src/Makefile.am, src/Makefile.in: Apply patch from Ubuntu to
>>> remove unknown -avoid-version from LDFLAGS. (Closes: #628245)
>>>
>>> Date: Tue, 25 Oct 2011 02:20:08 -0500
>>> Changed-By: Nicolas Valcárcel Scerpella 
>>> Maintainer: Ubuntu Developers 
>>> https://launchpad.net/ubuntu/precise/+source/aptsh/0.0.7+nmu2ubuntu1
>> This doesn't seem right, can you please reupload with the libreadline
>> that Debian used and a note that it should be sync'd next time unless
>> there's a reason to override Debian's libreadline choice?
>>
>> Thanks,
>> MIcah
>
> Once again Micah,  seems as if this message would have best been kept
> private between you and Nicolas.  We all know you're a smart dude, no
> need to be an ass about it.
>
> With love,
> Steve
>
This was a public upload that was sent to a mailing list monitored by
Ubuntu developers that resulted in a license violation.  The reason I
sent it to the list was 2 fold.  First, that others should be aware of
such things (i.e. possible license violations, although it was Colin who
actually spelled that out properly).  Second, that I was sure that I
wasn't going to be the only one to raise an eyebrow about this.  In
order to keep everyone on the same page, I moved the discussion to the
ubuntu-devel list.  This has been done before.  This is not about
pointing fingers, but about raising awareness and getting things fixed. 
We all make mistakes.  Sometimes, one person's error can be a learning
lesson for everyone.  I certainly hope no one is looking down on Nicolas
for this, I certainly am not.  In fact, it's because Nicolas did
something right, that this was able to be caught at all.  He included
the changelogs from Debian properly in his upload which allowed the
merge to be contrasted with what was done in Debian.

Thanks,
Micah
-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: [ubuntu/precise] aptsh 0.0.7+nmu2ubuntu1 (Accepted)

[Micah Gersten]

On 10/25/2011 10:26 AM, Nicolas Valcárcel Scerpella wrote:
> On Tue, 25 Oct 2011, Colin Watson wrote:
> 
>> On Tue, Oct 25, 2011 at 03:25:58AM -0500, Nicolas Valcárcel Scerpella wrote:
>>> We don't have that readline in our archive, i assume it's just a weird
>>> debian naming thing
>>
>> On the contrary:
>>
>>   libreadline-gplv2-dev | 5.2-11 |   precise | amd64, armel, i386, 
>> powerpc
>>
>> I second Micah's request; please revert your change ASAP, as it results
>> in a licence violation by linking a GPLv2-only package against a GPLv3
>> version of readline.
>>
>> -- 
>> Colin Watson   [cjwat...@ubuntu.com]
> Sorry, i don't know how i missed that one :S, ok, just reverted the
> change.

Thank you for your prompt attention on this, but I don't see the upload.
 Could you please verify that it actually made it to the archive?

Thanks,
Micah

-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: [ubuntu/precise] aptsh 0.0.7+nmu2ubuntu1 (Accepted)

[Micah Gersten]

* Fixed top post
On 10/25/2011 03:25 AM, Nicolas Valcárcel Scerpella wrote:
> On Tue, 25 Oct 2011, Micah Gersten wrote:
>
>> On 10/25/2011 02:25 AM, Nicolas Valcarcel Scerpella wrote:
>>> aptsh (0.0.7+nmu2ubuntu1) precise; urgency=low
>>>
>>> * Merge from debian unstable. Remaining changes:
>>> - debian/control: change Build-Depends from libreadline5-dev to
>>> libreadline-dev for readline transition.
>>>
>>> aptsh (0.0.7+nmu2) unstable; urgency=low
>>>
>>> * Non-maintainer upload.
>>> * debian/control: Build-Depend on libreadline-gplv2-dev instead of
>>> libreadline5-dev. (Closes: #553726)
>>> * src/Makefile.am, src/Makefile.in: Apply patch from Ubuntu to
>>> remove unknown -avoid-version from LDFLAGS. (Closes: #628245)
>>>
>>> Date: Tue, 25 Oct 2011 02:20:08 -0500
>>> Changed-By: Nicolas Valcárcel Scerpella 
>>> Maintainer: Ubuntu Developers 
>>> https://launchpad.net/ubuntu/precise/+source/aptsh/0.0.7+nmu2ubuntu1
>>>
>> This doesn't seem right, can you please reupload with the libreadline
>> that Debian used and a note that it should be sync'd next time unless
>> there's a reason to override Debian's libreadline choice?
>>
>> Thanks,
>> MIcah
> We don't have that readline in our archive, i assume it's just a weird
> debian naming thing
>
rmadison libreadline-gplv2-dev
libreadline-gplv2-dev | 5.2-9ubuntu1 |   oneiric | amd64, armel,
i386, powerpc
libreadline-gplv2-dev | 5.2-11 |   precise | amd64, armel, i386,
powerpc

Please fix :)

Thanks,
Micah

-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: [ubuntu/precise] aptsh 0.0.7+nmu2ubuntu1 (Accepted)

[Micah Gersten]

On 10/25/2011 02:25 AM, Nicolas Valcarcel Scerpella wrote:
> aptsh (0.0.7+nmu2ubuntu1) precise; urgency=low
>
>   * Merge from debian unstable.  Remaining changes:
> - debian/control: change Build-Depends from libreadline5-dev to
>   libreadline-dev for readline transition.
>
> aptsh (0.0.7+nmu2) unstable; urgency=low
>
>   * Non-maintainer upload.
>   * debian/control: Build-Depend on libreadline-gplv2-dev instead of
> libreadline5-dev. (Closes: #553726)
>   * src/Makefile.am, src/Makefile.in: Apply patch from Ubuntu to
> remove unknown -avoid-version from LDFLAGS. (Closes: #628245)
>
> Date: Tue, 25 Oct 2011 02:20:08 -0500
> Changed-By: Nicolas Valcárcel Scerpella 
> Maintainer: Ubuntu Developers 
> https://launchpad.net/ubuntu/precise/+source/aptsh/0.0.7+nmu2ubuntu1
>
This doesn't seem right, can you please reupload with the libreadline
that Debian used and a note that it should be sync'd next time unless
there's a reason to override Debian's libreadline choice?

Thanks,
MIcah
-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: Getting new packages into Ubuntu

[Micah Gersten]

On 10/10/2011 02:24 PM, Stefano Rivera wrote:
> Hi Sebastien (2011.10.10_20:34:48_+0200)
>> Well you would perhaps have run into some issues where you need upgrades
>> or fixes to the "platform" side and looked at the "main" archive to get
>> those solved? Or you would have just contributed to extras and reach
>> users which is a valid contributions as well...
> In fact I did (python-configobj), and now maintain that library in
> Debian. But I'm expecting that the ARB solution to that problem would be
> to bundle the newer library version. Otherwise, would we be expecting
> ARB to sort out the dependencies as SRUs?
>
> SR
>
I thought ARB was supposed to be lightweight apps, why would these
require (or even be allowed) to include library dependencies?

Micah

-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: Key signing party for UDS/Linaro in Orlando

[Micah Gersten]

On 10/03/2011 06:34 PM, Mackenzie Morgan wrote:
> On Mon, Oct 3, 2011 at 6:53 PM, Jorge O. Castro  wrote:
>> On Mon, Oct 3, 2011 at 6:32 PM, Christian Robottom Reis  
>> wrote:
>>> On Mon, Oct 03, 2011 at 12:20:38PM -0700, Deepak Saxena wrote:
 Is there usually a key-signing at UDS? If not, should we organize a
 Linaro one?
>>> Copying Jorge.
>>>
>>> Yes, there's usually always a massive key-signing at UDS; Jorge, can you
>>> get us details as to whether and when the Orlando one is?
>> As far as I can tell there hasn't been an officially scheduled
>> keysigning in a while, usually people organize one on their own after
>> hours, however in light of recent events it might be prudent to
>> organize one with Linaro on a certain day after sessions.
> Last one I remember at UDS was at Barcelona, organized by slangasek, I think.
>
There was one organized by sconklin in Brussels as well.

Micah

-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: Five build fixes a day

[Micah Gersten]

On 09/14/2011 06:39 AM, Colin Watson wrote:
> On Wed, Sep 14, 2011 at 01:27:00AM -0400, Scott Kitterman wrote:
>
>   python-pythonmagick (pythonmagick)
> Could use somebody who doesn't go cross-eyed looking at C++.
>
>>   frogatto
> I'm working on this now.
>
> You also missed a few on other architectures:
>
>   fracplanet [armel]
>   libgnuradio-core0 [armel] (gnuradio)
>   libgruel0 [armel] (gnuradio)
>   libplayerc++3.0 [armel] (player)
>   python-libavg [armel powerpc] (libavg)
>   toonloop [armel]
>
Hourly updated boost transition tracking can be found here:
http://people.canonical.com/~ubuntu-archive/transitions/boost1.46.html

Thanks,
Micah

-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: Five build fixes a day

[Micah Gersten]

On 09/12/2011 10:02 AM, Colin Watson wrote:
> We have 661 build failure bugs open right now:
>
>   https://bugs.launchpad.net/ubuntu/+bugs?field.tag=ftbfs
>
> The good news is that this is down from well over 700 yesterday, so we
> are making progress.
>
> The bad news is the build failure queue has been very long for ages, and
> we haven't been doing anything consistently effective about it;
> certainly some good people have been working on some failures, but the
> queue has dominated the effort available to deal with it for a while
> now.  As a result, we've had to exclude build failures from routine
> consideration in release meetings and the like.  That was pragmatically
> sensible (some of the binaries have been removed, the bulk of the bugs
> are against universe [1], etc.), but it really can't go on.  Being able
> to build your software reliably is one of the most fundamental tenets of
> software engineering, and any good team assigns a high priority to
> fixing build failures.
>
> Right now, there's a small number of us cranking through the build
> failure queue, but we have allowed this problem to build up far enough
> over time that it's going to take a somewhat more concerted effort to
> clear it.  On the upside, if we can get the queue down to zero or near
> zero and keep it there, other things will be easier later: it won't be
> as much effort to transition packages over to new libraries, users of
> (particularly) non-i386 architectures won't have as many problems due to
> build skew between i386 and other architectures, you won't find yourself
> making a change only to be sidetracked off into fixing a lurking build
> bug that's been hanging around for six months, or trying to make an
> entire software stack build on some new architecture.
>
>
> So: I am personally committing to upload fixes for *at least five build
> failures per day*, Monday to Friday, until such time as I run out of
> things I know or can teach myself how to fix.  My own experience is that
> I can do this and still have plenty of time to deal with other things in
> a working day.  If nine other people join me in this commitment, we
> should be able to clear the queue in under three weeks.  Who's with me?
>
> I'm expecting this to be mainly fairly experienced developers; fixing
> build failures is good practice, but you probably don't have much time
> to learn before Oneiric.  It probably isn't something to try if you're
> brand new to Ubuntu development.  But if you've already got your feet
> wet with Ubuntu package maintenance and want to try your hand at some of
> this, then these links may help:
>
>   http://wiki.debian.org/qa.debian.org/FTBFS
>   http://wiki.debian.org/ToolChain/DSOLinking
>   https://wiki.ubuntu.com/ARM/FTBFS
>
> Please remember to forward patches to Debian and usertag them
> appropriately (https://wiki.ubuntu.com/Debian/Usertagging, and note the
> usertags in http://wiki.debian.org/ToolChain/DSOLinking as well).
>
> If you want to work on bugs but don't yet know how to program or
> maintain packages, then you may prefer this instead:
>
>   https://wiki.ubuntu.com/5-A-Day
>
>
> [1] If your primary focus is main, you may be tempted to say "oh, they're
> in universe, so they don't matter very much".
>
> Firstly, the noise causes a problem in itself; many Launchpad bug
> views don't make it particularly easy to see what component bugs
> affect, and we often have to filter things out in order to do
> release management effectively.
>
> Secondly, we often have to promote packages from universe or fix
> problems in universe in order to meet user/customer demand or clean
> up various bits of the archive, so allowing universe buildability to
> be a swamp causes us velocity problems.
>
> Thirdly, we provide universe for the benefit of our users; even if
> Canonical engineers generally have main as their primary focus, we
> all lose out if our users are having upgrade problems due to a
> popular package in universe failing to build and so being stuck on
> an old version of a library that conflicts with other newer
> packages, or something like that. [2]
>
> [2] Longest footnote EVER.
>
>
> Cheers,
>
I can try to do this as an average of 25 per week.
Thanks,
Micah

-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Patch Pilot Report 2011-08-03

[Micah Gersten]

bug 819679 - Sync subtitleeditor (universe) 0.39.0 from debian
experimental (main).
 Builds fine, ACKd

bug 819774 - Please sync zsnes 1.510+bz2-1 (universe) from Debian
unstable (main)
 FTBFS, assigned to reporter, unsubscribed sponsors

gedit-plugin 3.1.2 merge
 approved, pushed, uploaded

Bug #813428 - [needs-packaging] aisleriot
 waiting on a new upstream release, unsubscribed sponsors

lp:~paulbrianstewart/ubuntu/oneiric/visualvm/813165-formattingTypo/+merge/68469
  patch looks good, but was wondering about the semantics of the words,
asked mpt for review

New upstream release, gearmand 0.23
 failed to build, also, newest upstream is now 0.24, set to incomplete,
assigned to submitter, unsubscribed sponsors

Saw 2 merge proposals for typo fixes in stable releases
 kicked off thread on ubuntu-devel about the issue

Bug #820721 - Sync parrot 3.6.0-1 (universe) from Debian unstable (main)
 builds on amd64, sync ACKd

Bug #803468  - [Need Packaging] New upstream release 0.143
 looked good, uploaded

-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

SRUs for typo fixes in descriptions

[Micah Gersten]

So, there are a couple merge proposals right now for control file
description typo fixes for natty:
https://code.launchpad.net/~bones/ubuntu/oneiric/gnomebaker/fix-for-818364/+merge/70234
https://code.launchpad.net/~bones/ubuntu/natty/radiotray/fix-for-722886/+merge/70107

The package has either been removed or fixed in the dev release, so
that's not an issue.
So, something like this would seeming be fine in conjunction with
another SRU, but wouldn't qualify on its own for one if I understand
correctly.
I'm wondering if there should be a queue for these fix only with
something else, or if we should just close won't fix (see SRU policy).

Thanks,
Micah

-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: Default libjpeg-dev in oneiric

[Micah Gersten]

On 07/29/2011 10:47 AM, Micah Gersten wrote:
> On 07/29/2011 02:39 AM, Steve Langasek wrote:
>> On Thu, Jul 28, 2011 at 06:13:49PM -0500, Kate Stewart wrote:
>>> On Thu, 2011-07-28 at 17:54 -0500, Micah Gersten wrote:
>>>> CCing ubuntu-devel so people are aware of the issue
>>>> Due to the accidental autosync, we pulled in a libjpeg8-dev that
>>>> provides libjpeg-dev.  Should we revert that one change (not provide
>>>> libjpeg-dev in libjpeg8) or should we try to do the transition?  There
>>>> are a number of incomplete transitions ATM (libnotify, libssl, libav,
>>>> boost1.4.6, and a few more with ~10 packages each).
>>>> Attached are a list of rdepends affected.
>>> ...ouch.
>>> Given we'll be putting out the A3 release next week, and I don't believe
>>> this update and transition is essential, my preference would be to
>>> revert it for now,  and then after A3's out,  assess if if makes sense
>>> to pull it in and manage the transition, or wait until P-series for this
>>> one.   
>>> Given all the stuff about to land for A3 and Feature Freeze almost upon
>>> us, it seems a bit risky to add this in,  esp. with folks going on
>>> vacation right now.
>>> What do others think?
>> I agree, best to back this out.  Micah, will you upload the necessary
>> change?  (Sooner better than later, so we don't drift too much while
>> libjpeg8-dev is the default?)
>>
> Actually, libjpeg8-dev isn't the default ATM. Anything with libjpeg-dev
> as a build depend will FTBFS since 2 packages provide the same virtual
> libjpeg-dev package.  I'll prepare an upload to fix, but I need it
> sponsored still.
> Thanks,
> Micah
>
This has been uploaded and should be available after the next publisher run.
Thanks,
Micah

-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: Default libjpeg-dev in oneiric

[Micah Gersten]

On 07/29/2011 02:39 AM, Steve Langasek wrote:
> On Thu, Jul 28, 2011 at 06:13:49PM -0500, Kate Stewart wrote:
>> On Thu, 2011-07-28 at 17:54 -0500, Micah Gersten wrote:
>>> CCing ubuntu-devel so people are aware of the issue
>>> Due to the accidental autosync, we pulled in a libjpeg8-dev that
>>> provides libjpeg-dev.  Should we revert that one change (not provide
>>> libjpeg-dev in libjpeg8) or should we try to do the transition?  There
>>> are a number of incomplete transitions ATM (libnotify, libssl, libav,
>>> boost1.4.6, and a few more with ~10 packages each).
>>> Attached are a list of rdepends affected.
>> ...ouch.
>> Given we'll be putting out the A3 release next week, and I don't believe
>> this update and transition is essential, my preference would be to
>> revert it for now,  and then after A3's out,  assess if if makes sense
>> to pull it in and manage the transition, or wait until P-series for this
>> one.   
>> Given all the stuff about to land for A3 and Feature Freeze almost upon
>> us, it seems a bit risky to add this in,  esp. with folks going on
>> vacation right now.
>> What do others think?
> I agree, best to back this out.  Micah, will you upload the necessary
> change?  (Sooner better than later, so we don't drift too much while
> libjpeg8-dev is the default?)
>
Actually, libjpeg8-dev isn't the default ATM. Anything with libjpeg-dev
as a build depend will FTBFS since 2 packages provide the same virtual
libjpeg-dev package.  I'll prepare an upload to fix, but I need it
sponsored still.
Thanks,
Micah

-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Default libjpeg-dev in oneiric

[Micah Gersten]

CCing ubuntu-devel so people are aware of the issue

Due to the accidental autosync, we pulled in a libjpeg8-dev that
provides libjpeg-dev.  Should we revert that one change (not provide
libjpeg-dev in libjpeg8) or should we try to do the transition?  There
are a number of incomplete transitions ATM (libnotify, libssl, libav,
boost1.4.6, and a few more with ~10 packages each).

Attached are a list of rdepends affected.

Thanks,
Micah
-- oneiric/main amd64 deps on libjpeg62:
compiz-plugins-main
dcraw
digikam
emacs23
eog
gimp
gstreamer0.10-plugins-good
gwenview
hpijs
hplip-cups
htmldoc
kde-runtime
kde-workspace-bin
kipi-plugins
krfb
krita
libcupsimage2
libdirectfb-extra
libdjvulibre21
libfltk1.1
libfontforge1
libgd2-noxpm
libgd2-xpm
libgdiplus
libgdk-pixbuf2.0-0
libgegl-0.0-0
libgphoto2-2
libgs9
libimlib2
libjasper1
libjpeg62-dbg
libjpeg62-dev
libkhtml5
libmagickcore3
libmng1
libpoppler13
libqt3-mt
libqtgui4
libreoffice-core
libreoffice-filter-binfilter
libsane
libtiff4
libvigraimpex2
libvncserver0
libwebkitgtk-1.0-0
libwebkitgtk-3.0-0
libwmf-bin
libwmf0.2-7
lsb-desktop
netpbm
openjdk-6-jre
openjdk-6-jre-headless
python-imaging
python-imaging-dbg
scribus
simple-scan
vino
xplanet
-- oneiric/main i386 deps on libjpeg62:
compiz-plugins-main
dcraw
digikam
emacs23
eog
gimp
gstreamer0.10-plugins-good
gwenview
hpijs
hplip-cups
htmldoc
kde-runtime
kde-workspace-bin
kipi-plugins
krfb
krita
libcupsimage2
libdirectfb-extra
libdjvulibre21
libfltk1.1
libfontforge1
libgd2-noxpm
libgd2-xpm
libgdiplus
libgdk-pixbuf2.0-0
libgegl-0.0-0
libgphoto2-2
libgs9
libimlib2
libjasper1
libjpeg62-dbg
libjpeg62-dev
libkhtml5
libmagickcore3
libmng1
libpoppler13
libqt3-mt
libqtgui4
libreoffice-core
libreoffice-filter-binfilter
libsane
libtiff4
libv4l-0
libvigraimpex2
libvncserver0
libwebkitgtk-1.0-0
libwebkitgtk-3.0-0
libwmf-bin
libwmf0.2-7
lsb-desktop
netpbm
openjdk-6-jre
openjdk-6-jre-headless
python-imaging
python-imaging-dbg
scribus
simple-scan
vino
xplanet
-- oneiric/main armel deps on libjpeg62:
compiz-plugins-main
dcraw
digikam
emacs23
eog
gimp
gstreamer0.10-plugins-good
gwenview
hpijs
hplip-cups
htmldoc
kde-runtime
kde-workspace-bin
kipi-plugins
krfb
krita
libcupsimage2
libdirectfb-extra
libdjvulibre21
libfltk1.1
libfontforge1
libgd2-noxpm
libgd2-xpm
libgdiplus
libgdk-pixbuf2.0-0
libgegl-0.0-0
libgphoto2-2
libgs9
libimlib2
libjasper1
libjpeg62-dbg
libjpeg62-dev
libkhtml5
libmagickcore3
libmng1
libpoppler13
libqt3-mt
libqtgui4
libreoffice-core
libsane
libtiff4
libv4l-0
libvigraimpex2
libvncserver0
libwebkitgtk-1.0-0
libwebkitgtk-3.0-0
libwmf-bin
libwmf0.2-7
lsb-desktop
netpbm
openjdk-6-jre
openjdk-6-jre-headless
pxljr
python-imaging
python-imaging-dbg
scribus
simple-scan
vino
xplanet
-- oneiric/main powerpc deps on libjpeg62:
compiz-plugins-main
dcraw
digikam
emacs23
eog
gimp
gstreamer0.10-plugins-good
gwenview
hpijs
hplip-cups
htmldoc
kde-runtime
kde-workspace-bin
kipi-plugins
krfb
krita
libcupsimage2
libdirectfb-extra
libdjvulibre21
libfltk1.1
libfontforge1
libgd2-noxpm
libgd2-xpm
libgdiplus
libgdk-pixbuf2.0-0
libgegl-0.0-0
libgphoto2-2
libgs9
libimlib2
libjasper1
libjpeg62-dbg
libjpeg62-dev
libkhtml5
libmagickcore3
libmng1
libpoppler13
libqt3-mt
libqtgui4
libreoffice-core
libreoffice-filter-binfilter
libsane
libtiff4
libv4l-0
libvigraimpex2
libvncserver0
libwebkitgtk-1.0-0
libwebkitgtk-3.0-0
libwmf-bin
libwmf0.2-7
lsb-desktop
netpbm
openjdk-6-jre
openjdk-6-jre-headless
python-imaging
python-imaging-dbg
scribus
simple-scan
vino
xplanet
-- oneiric/main build deps on libjpeg62-dev:
compiz-plugins-main
directfb
emacs23
eog
fontforge
gegl
gst-plugins-good0.10
jasper
kde-runtime
kde-workspace
kde4libs
kdenetwork
koffice
libgd-gd2-perl
libgdiplus
libgphoto2
libkdcraw
libmng
libvncserver
netpbm-free
openjdk-6
php5
pxljr
python-gd
python-imaging
simple-scan
webkit
xplanet
xscreensaver
-- oneiric/main amd64 deps on libjpeg62-dev:
libdirectfb-dev
libgd2-noxpm-dev
libgd2-xpm-dev
libmng-dev
libvncserver-dev
-- oneiric/main i386 deps on libjpeg62-dev:
libdirectfb-dev
libgd2-noxpm-dev
libgd2-xpm-dev
libmng-dev
libvncserver-dev
-- oneiric/main armel deps on libjpeg62-dev:
libdirectfb-dev
libgd2-noxpm-dev
libgd2-xpm-dev
libmng-dev
libvncserver-dev
-- oneiric/main powerpc deps on libjpeg62-dev:
libdirectfb-dev
libgd2-noxpm-dev
libgd2-xpm-dev
libmng-dev
libvncserver-dev
-- oneiric/universe amd64 deps on libjpeg62:
aaphoto
abiword
abiword-plugin-grammar
abiword-plugin-mathview
advi
aeskulap
amsn
analog
armagetronad
asc
aterm
aterm-ml
avifile-mjpeg-plugin
avifile-utils
blender
browser-plugin-gnash
bumprace
camstream
celestia-glut
celestia-gnome
cgi-mapserver
chimera2
ctwm
darkroom
darnwdl
dcmtk
directvnc
djplay
driftnet
dvgrab
edisplay
emacs-snapshot
emacs23-lucid
emboss
emboss-lib
enblend
encadre-image
enfuse
exactimage
exiftran
exrtools
fbi
fbtv
fgfs-atlas
fim
flam3
flightgear
flphoto
freedroid
gaia
gambas2-gb-qt-kde
gambas2-gb-qt-kde-html
gargoyle-free
geotiff-bin
gimp-gap
gimp-plugin-registry
gimp-ufraw
gmerlin
gmic
gmsh
gnash-common
gnash-cygnal

Re: packageset restrictions and archive reorg

[Micah Gersten]

On 07/25/2011 04:25 PM, Scott Kitterman wrote:
> On Monday, July 25, 2011 04:52:42 PM Micah Gersten wrote:
>> On 07/25/2011 03:46 PM, Scott Kitterman wrote:
>>> On Monday, July 25, 2011 03:48:38 PM Micah Gersten wrote:
>>>> On 07/25/2011 02:05 PM, Scott Kitterman wrote:
>>>>> On Monday, July 25, 2011 02:41:29 PM Mackenzie Morgan wrote:
>>>>> ...
>>>>>
>>>>>> There was a discussion about it on IRC last week starting at
>>>>>> http://irclogs.ubuntu.com/2011/07/18/%23ubuntu-devel.html#t20:43
>>>>>>
>>>>>> In particular, this is the part about whether MOTU can or can't touch
>>>>>> packages in package sets...
>>>>>>
>>>>>>so should we make it a habit of making teams to match when we
>>>>>> make new packagesets?
>>>>>>  Considering that AA always took care of components, we
>>>>>> probably ought adjust packageset change permissions to be union of DMB
>>>>>> and AA or similar.
>>>>>>yes.  but that is Hard.
>>>>>>(AIUI.)
>>>>>>  Unless we expect the DMB to take over regular migration of
>>>>>> stuff for transitions, etc.
>>>>>>maco: it's probably the most practical approach
>>>>>>  cjwatson: It's hard to have a union of teams.  It's not hard
>>>>>> to have a team with membership limited to AA+DMB that owns the
>>>>>> packageset.  That said, it needs discussion and consensus before being
>>>>>> done.
>>>>>>cjwatson: so then we just ask the TB "can you make packageset
>>>>>> $name with packages x,y,z and permissions to $team" and then never
>>>>>> have to bug you about that packageset again (for the most part...until
>>>>>> it needs a new package)
>>>>>>  When we approve a PPU, does this necessitate the creation of
>>>>>> a packageset?
>>>>>>persia: we often vote to create a packageset if the set being
>>>>>> requested seems reusable or is copied off someone else and is
>>>>>> therefore obviously being reused
>>>>>>  maco: Right, when there is a team.  My concern is that we
>>>>>> grant packageset teams exclusive authority over packages unique to
>>>>>> their packagesets (which is why packageset teams are required to have
>>>>>> core-dev as a member).
>>>>>>persia: i did not know of this requirement
>>>>>>  persia: in terms of Archive Reorg, I don't think PPU should
>>>>>> have a packageset
>>>>>>  This is incompatible with our statement that we *do not*
>>>>>> grant exclusive authority over packages for PPUs, once MOTU is
>>>>>> implemented as the inverse of all packagesets.
>>>>>>   maco: if the package set is DMB-owned (some are like mozilla,
>>>>>> zope and some others) the DMB can add and remove packages from it once
>>>>>> the TB created the package set
>>>>>>  maco: Failure to abide by the requirement today has a low
>>>>>> penalty, as Soyuz still supports component-based permissions.
>>>>> Package set members having exclusive lock on packages is something that
>>>>> has been discussed, but AIUI (except for packagesets corresponding to
>>>>> Main) there are no such restrictive packagesets in place.  I can't
>>>>> imagine why if I, to pick a random example, was part of the uploaders
>>>>> for a Mono package set I would want to make it harder for other Ubuntu
>>>>> developers to help with it.
>>>>>
>>>>> I know that restrictive package sets was part of the original vision,
>>>>> but I don't recall that ALL package sets were to be restrictive.  This
>>>>> just seems like a recipe for increased balkanization in the Ubuntu
>>>>> developer community. I don't think it's a good idea (regardless of it
>>>>> was originally intended or not).
>>>>>
>>>>> Scott K
>>>> AIUI, it wasn't that all packagesets would be totally restrictive in the
>>>> reorg, but rather they would be core-dev + packageset uploaders for the
>>>> ACLs.  The only difference WRT now would be MOTU access to current
>>>> universe packages.  I think

packageset restrictions and archive reorg (was: Re: "What I like least in Ubuntu")

[Micah Gersten]

On 07/25/2011 03:46 PM, Scott Kitterman wrote:
> On Monday, July 25, 2011 03:48:38 PM Micah Gersten wrote:
>> On 07/25/2011 02:05 PM, Scott Kitterman wrote:
>>> On Monday, July 25, 2011 02:41:29 PM Mackenzie Morgan wrote:
>>> ...
>>>
>>>> There was a discussion about it on IRC last week starting at
>>>> http://irclogs.ubuntu.com/2011/07/18/%23ubuntu-devel.html#t20:43
>>>>
>>>> In particular, this is the part about whether MOTU can or can't touch
>>>> packages in package sets...
>>>>
>>>>  so should we make it a habit of making teams to match when we
>>>> make new packagesets?
>>>>Considering that AA always took care of components, we
>>>> probably ought adjust packageset change permissions to be union of DMB
>>>> and AA or similar.
>>>>  yes.  but that is Hard.
>>>>  (AIUI.)
>>>>Unless we expect the DMB to take over regular migration of
>>>> stuff for transitions, etc.
>>>>  maco: it's probably the most practical approach
>>>>cjwatson: It's hard to have a union of teams.  It's not hard
>>>> to have a team with membership limited to AA+DMB that owns the
>>>> packageset.  That said, it needs discussion and consensus before being
>>>> done.
>>>>  cjwatson: so then we just ask the TB "can you make packageset
>>>> $name with packages x,y,z and permissions to $team" and then never
>>>> have to bug you about that packageset again (for the most part...until
>>>> it needs a new package)
>>>>When we approve a PPU, does this necessitate the creation of
>>>> a packageset?
>>>>  persia: we often vote to create a packageset if the set being
>>>> requested seems reusable or is copied off someone else and is
>>>> therefore obviously being reused
>>>>maco: Right, when there is a team.  My concern is that we
>>>> grant packageset teams exclusive authority over packages unique to
>>>> their packagesets (which is why packageset teams are required to have
>>>> core-dev as a member).
>>>>  persia: i did not know of this requirement
>>>>persia: in terms of Archive Reorg, I don't think PPU should
>>>> have a packageset
>>>>This is incompatible with our statement that we *do not*
>>>> grant exclusive authority over packages for PPUs, once MOTU is
>>>> implemented as the inverse of all packagesets.
>>>> maco: if the package set is DMB-owned (some are like mozilla,
>>>> zope and some others) the DMB can add and remove packages from it once
>>>> the TB created the package set
>>>>maco: Failure to abide by the requirement today has a low
>>>> penalty, as Soyuz still supports component-based permissions.
>>> Package set members having exclusive lock on packages is something that
>>> has been discussed, but AIUI (except for packagesets corresponding to
>>> Main) there are no such restrictive packagesets in place.  I can't
>>> imagine why if I, to pick a random example, was part of the uploaders
>>> for a Mono package set I would want to make it harder for other Ubuntu
>>> developers to help with it.
>>>
>>> I know that restrictive package sets was part of the original vision, but
>>> I don't recall that ALL package sets were to be restrictive.  This just
>>> seems like a recipe for increased balkanization in the Ubuntu developer
>>> community. I don't think it's a good idea (regardless of it was
>>> originally intended or not).
>>>
>>> Scott K
>> AIUI, it wasn't that all packagesets would be totally restrictive in the
>> reorg, but rather they would be core-dev + packageset uploaders for the
>> ACLs.  The only difference WRT now would be MOTU access to current
>> universe packages.  I think the understanding is that if we have a
>> packageset, we have a subset of people caring for those packages.  Any
>> qualified person wishing to care for these packages can then apply for
>> the packageset.  MOTU would serve as generalists for the packages that
>> have no particular group taking care of them in the archive.
> I don't see any advantage to such a system over MOTU as generalists who care 
> for packages outside of restricted packagesets (and restricted package sets 
> are limited to what was historically Main and only expanded after a lot of 
> consideration).  I see lots of disadvantag

Re: "What I like least in Ubuntu"

[Micah Gersten]

On 07/25/2011 02:05 PM, Scott Kitterman wrote:
> On Monday, July 25, 2011 02:41:29 PM Mackenzie Morgan wrote:
> ...
>> There was a discussion about it on IRC last week starting at
>> http://irclogs.ubuntu.com/2011/07/18/%23ubuntu-devel.html#t20:43
>>
>> In particular, this is the part about whether MOTU can or can't touch
>> packages in package sets...
>>
>>so should we make it a habit of making teams to match when we
>> make new packagesets?
>>  Considering that AA always took care of components, we
>> probably ought adjust packageset change permissions to be union of DMB
>> and AA or similar.
>>yes.  but that is Hard.
>>(AIUI.)
>>  Unless we expect the DMB to take over regular migration of
>> stuff for transitions, etc.
>>maco: it's probably the most practical approach
>>  cjwatson: It's hard to have a union of teams.  It's not hard
>> to have a team with membership limited to AA+DMB that owns the
>> packageset.  That said, it needs discussion and consensus before being
>> done.
>>cjwatson: so then we just ask the TB "can you make packageset
>> $name with packages x,y,z and permissions to $team" and then never
>> have to bug you about that packageset again (for the most part...until
>> it needs a new package)
>>  When we approve a PPU, does this necessitate the creation of
>> a packageset?
>>persia: we often vote to create a packageset if the set being
>> requested seems reusable or is copied off someone else and is
>> therefore obviously being reused
>>  maco: Right, when there is a team.  My concern is that we
>> grant packageset teams exclusive authority over packages unique to
>> their packagesets (which is why packageset teams are required to have
>> core-dev as a member).
>>persia: i did not know of this requirement
>>  persia: in terms of Archive Reorg, I don't think PPU should
>> have a packageset
>>  This is incompatible with our statement that we *do not*
>> grant exclusive authority over packages for PPUs, once MOTU is
>> implemented as the inverse of all packagesets.
>>   maco: if the package set is DMB-owned (some are like mozilla,
>> zope and some others) the DMB can add and remove packages from it once
>> the TB created the package set
>>  maco: Failure to abide by the requirement today has a low
>> penalty, as Soyuz still supports component-based permissions.
> Package set members having exclusive lock on packages is something that has 
> been discussed, but AIUI (except for packagesets corresponding to Main) there 
> are no such restrictive packagesets in place.  I can't imagine why if I, to 
> pick a random example, was part of the uploaders for a Mono package set I 
> would want to make it harder for other Ubuntu developers to help with it.
>
> I know that restrictive package sets was part of the original vision, but I 
> don't recall that ALL package sets were to be restrictive.  This just seems 
> like a recipe for increased balkanization in the Ubuntu developer community.  
> I don't think it's a good idea (regardless of it was originally intended or 
> not).
>
> Scott K
>
AIUI, it wasn't that all packagesets would be totally restrictive in the
reorg, but rather they would be core-dev + packageset uploaders for the
ACLs.  The only difference WRT now would be MOTU access to current
universe packages.  I think the understanding is that if we have a
packageset, we have a subset of people caring for those packages.  Any
qualified person wishing to care for these packages can then apply for
the packageset.  MOTU would serve as generalists for the packages that
have no particular group taking care of them in the archive.

Micah

-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: Reminder to update timestamps before sponsoring (or maybe not :))

[Micah Gersten]

On 07/07/2011 12:23 AM, Scott Kitterman wrote:
> On Thursday, July 07, 2011 01:19:07 AM Micah Gersten wrote:
>> smarty3 (3.0.8-0ubuntu1) oneiric; urgency=low
>>
>>> * New upstream release. (LP: #801924)
>>>
>>> Date: Sat, 25 Jun 2011 12:38:31 +0100
>>> Changed-By: Mat Scales 
>>> Maintainer: Ubuntu Developers 
>>> Signed-By: Micah Gersten 
>>> https://launchpad.net/ubuntu/oneiric/+source/smarty3/3.0.8-0ubuntu1
>> I goofed here, but seems like it's a good opportunity for another PSA
>> (Public Service Announcement) since I found a handful of others like
>> it in the last 24 hours.  One should try to update the timestamp
>> before sponsoring/uploading a package.  This can be accomplished with
>> either 'dch -m -r' for sponsoring or just 'dch -r' for one's own upload.
> Why should one do this?
>
> Scott K
>
Apparently I thought it was a good idea and was under the impression
that it was widely done, but I find no reference to updated timestamps
in Debian policy, so I guess this was all in my head.  I apologize for
the noise.  I will however explain why I think it's a good idea in any case.
The changelog is what is pushed to the user's system and also is a
snapshot of the history of the package.  When I was commenting above
about timestamps being off, I was referring to where it was off by more
than one day, not just a few hours or minutes.  This seems
counterintuitive to see something uploaded on a certain date, but dated
much before then.  It would seem to make sense to keep this relatively
in line with when events occur.

Perhaps someone with a historical perspective can explain what the
intended goal of the timestamp in the changelog was.

Thanks,
Micah

-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Reminder to update timestamps before sponsoring (was: Re: [ubuntu/oneiric] smarty3 3.0.8-0ubuntu1 (Accepted))

[Micah Gersten]

smarty3 (3.0.8-0ubuntu1) oneiric; urgency=low
>
> * New upstream release. (LP: #801924)
>
> Date: Sat, 25 Jun 2011 12:38:31 +0100
> Changed-By: Mat Scales 
> Maintainer: Ubuntu Developers 
> Signed-By: Micah Gersten 
> https://launchpad.net/ubuntu/oneiric/+source/smarty3/3.0.8-0ubuntu1

I goofed here, but seems like it's a good opportunity for another PSA
(Public Service Announcement) since I found a handful of others like
it in the last 24 hours.  One should try to update the timestamp
before sponsoring/uploading a package.  This can be accomplished with
either 'dch -m -r' for sponsoring or just 'dch -r' for one's own upload.

Micah

-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: Please test AirPrint on Natty and Oneiric

[Micah Gersten]

On 06/28/2011 05:52 PM, Daniel Chen wrote:
>
> Hi Till,
>
> On Jun 28, 2011 10:31 AM, "Till Kamppeter"  > wrote:
> >
> > Before reporting bugs, please check your CUPS package version. It
> must be 1.4.6-5ubuntu1.3 on Natty and 1.4.6-11 on Oneiric. Wait for
> the mirrors to catch up if needed.
> >
>
> Did you mean -9 for Oneiric? I don't see -11 on Launchpad or Debian
> PTS (or Incoming), only -9.
>
> Cheers,
> -Dan
>

It was just upload to Oneiric a few minutes ago.
Micah
-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: python-oauth (version question)

[Micah Gersten]

On 06/23/2011 02:32 PM, Barry Warsaw wrote:
> Hi Rodney, Martin,
>
> As part of our bug 788514 efforts to get rid of python-support and
> python-central on our CDs, I've run across python-oauth.  There's good news
> and bad news ;).
>
> The good news: Debian has version 1.0.1-3 which tracks upstream's 1.0.1, the
> most current release on the Cheeseshop.  It has already been converted to
> dh_python2.
>
> The bad news: well, there's several!  Since you guys are the last to touch the
> package on Ubuntu, I'm hoping you can shed some light.  Note that AFAICT, it
> was last modified in Karmic.
>
> * The version numbers are borked.  Ubuntu has 1.0a~svn1124-0ubuntu2 while sid
>   has 1.0.1-3.  The Ubuntu version number is higher, but it represents an
>   older version of the upstream library.  So we'll have to play games with the
>   version numbers when we update the Ubuntu package.
>   (e.g. 1.0a.isreally.1.0.1-3ubuntu1 or some such).

This isn't true, the new Debian version is higher.
~$ dpkg --compare-versions 1.0a~svn1124-0ubuntu2 gt 1.0.1-3 && echo 1
~$ dpkg --compare-versions 1.0a~svn1124-0ubuntu2 lt 1.0.1-3 && echo 1
1


-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: Call For Testing: Natty Firefox users (or willing to install Natty in a VM)

[Micah Gersten]

On 06/17/2011 05:59 PM, Micah Gersten wrote:
>
> We need Natty users to test our latest Firefox Upgrade!
>
> *Background:*
> Firefox 4 will not receive any more point releases, but rather Firefox
> 5 is the security update for Firefox 4.0.1. Upstream Mozilla has
> changed their release process and are using a rapid release schedule. 
> We will be following this new release schedule to continue to deliver
> a secure browsing experience to our users.
>
> Since Natty has Firefox 4, it will start this process immediately.
> Lucid and Maverick which are on 3.6.x will be transitioning to the new
> rapid release cycle once 3.6.x has reached end of life.
>
> Before releasing these updates to the public, we need testing of the
> following packages:
>
> * firefox
> * xul-ext-webfav
> * xul-ext-mozvoikko
> * xul-ext-bindwood
> * gecko-mediaplayer
> * moonlight-plugin-core
>
> We have published all these packages in a PPA [1], and, for your
> convenience, have copied these updates to natty-proposed.  You can
> either enable the Ubuntu Mozilla Security PPA (instructions to follow)
> or natty-proposed.  Please keep in mind, that natty-proposed might get
> you a lot of other extra packages as well.
>
> We need people running Natty in bare metal or a virtual machine. If
> you are willing to help, here's what you can do:
>
> Add the Ubuntu Mozilla Security PPA to your software sources:
> sudo add-apt-repository ppa:ubuntu-mozilla-security/ppa
> or
> enable natty-proposed
>
> Then, you can either run update-manager or:
> sudo apt-get update && sudo apt-get dist-upgrade
>
> Since there are very few packages, we are tracking this transition in
> bug 798484 [2].  I have added verification-needed-* tags for each of
> the packages that need testing.  If you find a bug, please file a new
> bug with all the details, then, comment with the bug # and the
> affected package name in the tracking bug [2].  If you see the
> verification-needed-* tag for a specific package, feel free to comment
> if you have tested the package and it works.  If you see a
> verification-done-* tag for a specific package, there is no need to
> comment that it works, but more testing is always appreciated.If
> you see a verification-failed-* tag for a specific package, please
> check if your bug has already been filed, if not, please file one with
> all the details and comment in the tracking bug with the bug # and the
> package name.
>
> Feel free to subscribe to this bug [2] to follow the progress, but be
> forewarned that you will probably get a lot of E-Mail from it.
>
> Please note, packages need to be tested to migrate to natty-security
> and natty-updates.
>
> Thanks to everyone in advance,
> Micah
>
> [1] https://launchpad.net/~ubuntu-mozilla-security/+archive/ppa
> <https://edge.launchpad.net/%7Eubuntu-mozilla-security/+archive/ppa>
> [2] https://bugs.launchpad.net/bugs/798484
>
> P.S.  The current final Firefox 5 build and moon are currently
> finishing building on armel and will be copied to natty-proposed over
> the weekend.  The other architectures' packages are available in the
> Ubuntu Mozilla Security PPA.
> -- 
> Micah Gersten
> Ubuntu Security Team

I want to apologize for leaving out this piece of information.  If
you're testing in natty-proposed everything is fine.  If you're testing
from the Ubuntu Mozilla Security PPA, anything that requires a language
pack will fail.  This is due to us switching to in source Firefox
language packs.  natty-proposed contains updated system language packs
which pull in the appropriate language pack from the firefox source.

Thank you,
Micah
-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Call For Testing: Natty Firefox users (or willing to install Natty in a VM)

[Micah Gersten]

We need Natty users to test our latest Firefox Upgrade!

*Background:*
Firefox 4 will not receive any more point releases, but rather Firefox 5
is the security update for Firefox 4.0.1. Upstream Mozilla has changed
their release process and are using a rapid release schedule.  We will
be following this new release schedule to continue to deliver a secure
browsing experience to our users.

Since Natty has Firefox 4, it will start this process immediately. Lucid
and Maverick which are on 3.6.x will be transitioning to the new rapid
release cycle once 3.6.x has reached end of life.

Before releasing these updates to the public, we need testing of the
following packages:

* firefox
* xul-ext-webfav
* xul-ext-mozvoikko
* xul-ext-bindwood
* gecko-mediaplayer
* moonlight-plugin-core

We have published all these packages in a PPA [1], and, for your
convenience, have copied these updates to natty-proposed.  You can
either enable the Ubuntu Mozilla Security PPA (instructions to follow)
or natty-proposed.  Please keep in mind, that natty-proposed might get
you a lot of other extra packages as well.

We need people running Natty in bare metal or a virtual machine. If you
are willing to help, here's what you can do:

Add the Ubuntu Mozilla Security PPA to your software sources:
sudo add-apt-repository ppa:ubuntu-mozilla-security/ppa
or
enable natty-proposed

Then, you can either run update-manager or:
sudo apt-get update && sudo apt-get dist-upgrade

Since there are very few packages, we are tracking this transition in
bug 798484 [2].  I have added verification-needed-* tags for each of the
packages that need testing.  If you find a bug, please file a new bug
with all the details, then, comment with the bug # and the affected
package name in the tracking bug [2].  If you see the
verification-needed-* tag for a specific package, feel free to comment
if you have tested the package and it works.  If you see a
verification-done-* tag for a specific package, there is no need to
comment that it works, but more testing is always appreciated.If you
see a verification-failed-* tag for a specific package, please check if
your bug has already been filed, if not, please file one with all the
details and comment in the tracking bug with the bug # and the package name.

Feel free to subscribe to this bug [2] to follow the progress, but be
forewarned that you will probably get a lot of E-Mail from it.

Please note, packages need to be tested to migrate to natty-security and
natty-updates.

Thanks to everyone in advance,
Micah

[1] https://launchpad.net/~ubuntu-mozilla-security/+archive/ppa
<https://edge.launchpad.net/%7Eubuntu-mozilla-security/+archive/ppa>
[2] https://bugs.launchpad.net/bugs/798484

P.S.  The current final Firefox 5 build and moon are currently finishing
building on armel and will be copied to natty-proposed over the
weekend.  The other architectures' packages are available in the Ubuntu
Mozilla Security PPA.

-- 
Micah Gersten
Ubuntu Security Team

-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: New Launchpad feature: Diff between Sid and Oneiric

[Micah Gersten]

On 06/16/2011 04:26 AM, Dave Walker wrote:
> 
> * The new page should probably indicate the sponsor of the Ubuntu
> upload (if present).
> 
> Thanks again!
>
> Kind Regards,
> Dave Walker
>
>
Actually, the "uploader" on this page is the sponsor.  It should really
show the person who got credit for the upload as that person is
considered TIL.

Thanks,
Micah

-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: release cadence for Q and R

[Micah Gersten]

On 06/15/2011 05:58 PM, Steve Beattie wrote:
> On Wed, Jun 15, 2011 at 02:48:58PM -0700, Allison Randal wrote:
>> Very valuable perspective, thanks. To other upstreams, do you have
>> similar or opposite needs?
> Perhaps this is just me being naive, but with upstreams, shouldn't we
> be emphasizing the Feature Freeze date rather than the actual Release
> date? That's the merge window deadline they should be targeting, and
> where the Ubuntu cadence should be most relevant. This is at least how
> the upstream I do release management for targets the Ubuntu releases.
>
> Going back through the previous calendars, it seems that we've had
> Feature Freeze be 9 weeks before release on non-LTS releases and 10
> weeks prior on LTS releases (until you go back to Feisty where it
> starts to deviate).
>
> I also note that looking at the current draft Q schedule and R
> schedules, Feature Freeze is tentatively marked in at 11 weeks and
> 10 weeks prior to the respective releases. So even if the Q and R
> release cycles were moved to straight 26 week cycles, unless the
> Feature Freeze dates are also aligned, upstreams won't really have
> a 26 week cadence to target for development.
>
Indeed, but something to remember is that certain upstreams (KDE and
GNOME amongst others), have a microrelease exception which allows the
point releases to be included.  These were granted since no new features
are included in point releases.  I believe this is the point Scott K was
raising in that we get an extra round of bug fixes if we do a 26/26
split on the fall release.

Micah

-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: [dpkg-dev] auto-generated patch too easily included (debian/patches/debian-changes-*))

[Micah Gersten]

On 06/15/2011 12:40 PM, Dave Walker wrote:
>
> Hi,
>
> Currently, if the upstream code is changed (anything other than
> debian/*).. When dpkg-buildpackage is run, an automated patch is
> created. This is a really nice feature, but it is very easy to miss
> this. I have seen multiple uploads where these auto-generated patches
> have been included accidentally (I have also been guilty of this).
>
> This can be overridden locally with:
> $ cat ~/.devscripts
> DEBUILD_DPKG_BUILDPACKAGE_OPTS="--source-option=--abort-on-upstream-changes"
>
> I think the chance of someone wanting an auto-generated patch is low,
> and would like to suggest the default is changed to fail to create the
> source package.
>
> The alternative fix would be a dput hook.
>
> Thoughts?
>
> I have raised a bug to track this:
> https://launchpad.net/bugs/797839
>
> Kind Regards,
> Dave Walker
>

I actually use this as a feature.  I modify the upstream code, create a
source package, then rename the patch and add DEP-3 info.

Micah
-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

when not to use an epoch and how to avoid a sync (was: Re: [ubuntu/oneiric] nvidia-common 1:0.2.30+1 (Accepted))

[Micah Gersten]

On 06/04/2011 05:25 AM, Alberto Milone wrote:
> nvidia-common (1:0.2.30+1) oneiric; urgency=low
>
> * Add epoch to override the sync. The packages in Debian and Ubuntu
> have the same name but different code and scope (LP: #792576).
>

So, in Ubuntu we have a sync blacklist to avoid syncing something from
Debian.  There's no need to add an epoch to avoid this.  In fact, adding
an epoch will not necessarily help, since you never know when Debian
will add one as well.

The process for requesting something to be blacklisted from being sync'd
from Debian is to simply file a bug against the package and subscribe
ubuntu-sponsors if you cannot upload the package (to verify if this is
indeed the correct course of action) or subscribe ubuntu-archive and set
the status to confirmed if you can upload the package.

Adding an epoch makes it harder to get back in sync with Debian.  It
requires manual intervention until Debian has a situation where they add
a similar epoch.  Granted, that for this package, it might not happen
for a while; but, if we ever were to get these packages in sync, we are
now stuck with the epoch forever.

Generally, people have been using BAD_VERSION+reallyGOOD_VERSION when
something like this happens to avoid having to add an epoch.

IMHO, epochs should not be used in Ubuntu at all for this very reason.

In order to prevent autosyncs in the future, one can use an x.y-0ubuntu1
or x.yubuntu1 version scheme.

Micah
-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Using -v when merging from Debian

[Micah Gersten]

This is a friendly reminder that when merging a package from Debian,
to use -v when building the source package.  You pass it the last
version that was in Ubuntu and it'll include everything after that in
the _source.changes file.  This allows all the recorded changes to
show up on the -changes mailing list and any LP bugs closed in Debian
to be auto-closed.

Thanks,
Micah


-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: [ubuntu/oneiric] pdf2djvu 0.7.7-1ubuntu1 (Accepted)

[Micah Gersten]

On 05/24/2011 10:12 PM, Steve Stalcup wrote:
> Hi Micah,
>
> On Tue, May 24, 2011 at 8:50 PM, Micah Gersten  wrote:
>
>> I'd like to take this opportunity to publicize the command dch -R for
>> no change rebuilds.  It DTRT most of the time.  It appends and
>> increments buildX or just increments ubuntuX.
>>
>> Micah
> A poke on IRC could have accomplished the same thing.  Consider
> bringing it up privately first next time :)
>
> Steve
>
Sorry, my intent was to focus on the upload and not the uploader. 
That's why I removed the uploader from the E-Mail.  I've seen quite a
few people who were unaware of the command, so I thought Public Service
Announcement was a good idea.  I realized I forgot to change the subject
as well.

Micah


-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: [ubuntu/oneiric] pdf2djvu 0.7.7-1ubuntu1 (Accepted)

[Micah Gersten]

> pdf2djvu (0.7.7-1ubuntu1) oneiric; urgency=low
>
> * Rebuild
> * Bump standards version to 3.9.2
>

I'd like to take this opportunity to publicize the command dch -R for
no change rebuilds.  It DTRT most of the time.  It appends and
increments buildX or just increments ubuntuX.

Micah

-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: Please do not use syncpackage during hard-freeze periods

[Micah Gersten]

On 04/02/2011 08:08 AM, Artur Rona wrote:
> 
> Why universe is hard-frozen as well?

There are quite a few universe packages that are seeded as well
(xubuntu, mythbuntu, ubuntu-studio).  Those shouldn't be touched during
freezes either without the proper ACKs.

Micah

-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: Patch Pilot Report 2011-03-18

[Micah Gersten]

On 03/18/2011 03:53 PM, Scott Moser wrote:
> Hi,
>I have only PPU access to the Ubuntu archive, and no items in the list
> fell into my permissions, so I mainly just review and get things into
> better state for the next person.
>
>I have one general question, if something should not really be on the
> queue, what should be done ?  Specifically, bug 696560 is in a
> "waiting for input from the patch author" state.  It seems like it would
> be best to get such things off of that queue so other patch sponsors do
> not waste time coming to the same conclusion.
>
> 
You can unsubscribe ubuntu-sponsors and ask that the patch author
resubscribe when ready.  Ask dholbach or another admin of the team to
add you.

Micah

-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel