Summary of CUT discussions (Was: unstable/testing/[pending/frozen/]stable)

[Lucas Nussbaum]

On 22/09/10 at 15:01 +0200, Raphael Hertzog wrote:
> Hi all,
> 
> On Tue, 21 Sep 2010, Yaroslav Halchenko wrote:
> > CUT discussions at debconf10 and recent news of the birth of Linux Mint
> 
> discussions on CUT have continued after debconf on the CUT mailing. I
> wrote a summary of the discussion that will be published in Linux Weekly
> News before tomorrow.
> 
> Hopefully this summary will then lead to a constructive discussion on the
> way forward.

Hi,

Raphael's article is now published, and is probably a good basis for
discussing CUT on -de...@.
Free link: http://lwn.net/SubscriberLink/406301/bd522adc828b3461/

I also had prepared a summary of CUT discussion before Raphael worked on
his article, which can also be useful to understand the global picture:
http://lists.alioth.debian.org/pipermail/cut-team/2010-August/71.html
It would probably need some more work though, so please read it with
care (see the follow-up messages, too).

- Lucas


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100923070031.ga24...@xanadu.blop.info

Re: Debian ppa

[Joerg Jaspert]

> I still believe that this can and should be implemented. If someone is
> interested, I'm happy to help; I assume the same holds for Joerg.

True.

-- 
bye, Joerg
Yeah, patching debian/rules sounds like changing shoes while running the
100 meters track.
  -- Michael Koch


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87zkv9szkc@gkar.ganneff.de

Re: debdelta back online

[Javier Fernandez-Sanguino]

On 22 September 2010 22:46, A Mennucc  wrote:
> due to my PC running out of disk space, no deltas were generated in the
> last week (while I was absent); I found more space, so it will be back
> online as soon as it generates all needed deltas.

Question: How much space does debdelta take? (per architecture?) You
might need to provide figures if you want some "big Debian server" to
host this service...

Regards

Javier


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/aanlktinv2-ebtk1zfspick-bhvpceoz4gcd2vf403...@mail.gmail.com

Re: A new Priority level, ‘backports’ ? (Re: unstable/testing/[pending/frozen/]stable)

[Joerg Jaspert]

> the addition of new suites has the disadvantage of dispersing our userbase.
> Here is a proposition that conserves the current flow of package migration for
> packages released in Stable, and that makes Testing the meeting point for all
> the packages. 

> We could introduce a new priority level, ‘backports’, with the following
> features:

This whole thing does not make sense at all. Priority is the wrong knob.

>  This priority level would be lower than ‘extra’. Higher levels would not be
>  allowed to depend nor build-depend on packages of priority ‘backports’. 
> Source
>  packages would not be allowed to contain a mixture binary packages containing
>  ‘backports’ level and higher priorities.

>  These packages would not be released in Stable, but would be uploaded to
>  Unstable and migrate in Testing as usual, with the exception that they would
>  not be affected by a freeze. They could be removed by default from Testing in
>  case they block a transition.

>  As the name indicates, the packages which prove their stability in Testing
>  (and only them, as in the current backports rules) would be backported in
>  backports.debian.org. The backports would be prepared by the maintainers
>  themselves (this would open a way to the use of the BTS) and would be the 
> final
>  distribution medium for Stable users.

So what backports "priority" actually says is "my package is such a
bullshit that I don't want it ever released, but I am fine with putting
burden on the people keeping backports running instead". I think we have
a way already dealing with this: Don't upload them.


-- 
bye, Joerg
'To Start Press Any Key'. Where's the ANY key? 


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87vd5xszdd@gkar.ganneff.de

Re: Backports service becoming official

[Joerg Jaspert]

>> From what concerns the BTS, Don's proposal in [2] (the main one, not
>> the alternative solution) seems reasonable to me and others in the
>> thread. The proposal also seems to assume a different Maintainer
>> field for the bpo package, as hinted above, am I wrong Don?
> Right. The idea here is that there will be an additional recipient for
> bugs which affect the version present in bpo; in the case where the
> bug is bpo only, headers in the message will allow maintainers to
> filter out these bugs in mail and the bug listings. [Possibly even by
> default, but the opt-in mechanism is harder than the default-in to
> implement.]

Stepping in sideways here, but in case you can make use of them,
backports is creating the same debversion info like the main
archive. Want them synced to the bts?

-- 
bye, Joerg
(13:24)  ist iptables eigentlich nur ein tool zum
verhindern von aussenkonnectierungen auf gewissen ports oder ist
iptables eine firewall?
(13:27)  ist ein packet filter
(13:27)  maxx: also der verhindert pings?


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87r5glsz9u@gkar.ganneff.de

Re: Debian ppa

[Stefano Zacchiroli]

On Thu, Sep 23, 2010 at 04:31:57PM +1000, William Grant wrote:
> While Launchpad.net does not provide Debian PPAs, what prevents you from
> taking the Launchpad code, rebranding it, and running your own instance?
> It does require some changes to work with Debian's suites, but that
> would be far easier than reimplementing all the functionality yourself.

This was discussed in the past already. Nothing "prevents" us to do
that, but PPA is actually quite tied to Launchpad infrastructure which
is significantly different than the Debian infrastructure which is more
distributed and loosely coupled. So the blocker is simply finding
someone doing the needed porting work, possibly generalizing the code
for the benefit of everyone willing to setup something like that.

Show me the code! :-)

-- 
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
z...@{upsilon.cc,pps.jussieu.fr,debian.org} -<>- http://upsilon.cc/zack/
Quando anche i santi ti voltano le spalle, |  .  |. I've fans everywhere
ti resta John Fante -- V. Caposella ...| ..: |.. -- C. Adams


signature.asc
Description: Digital signature

Re: A new Priority level, ‘ backports ’ ? (Re: unstable/testing/[pending/frozen/]stable)

[Charles Plessy]

Le Thu, Sep 23, 2010 at 09:17:02AM +0200, Joerg Jaspert a écrit :
> 
> So what backports "priority" actually says is "my package is such a
> bullshit that I don't want it ever released, but I am fine with putting
> burden on the people keeping backports running instead". I think we have
> a way already dealing with this: Don't upload them.

These packages are not that bad, since the FTP team accepted them…

Cheers,

-- 
Charles


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100923081249.gc14...@merveille.plessy.net

Re: Re: Google Summer of Code 2010 Debian Report

[Filipus Klutiero]

 Obey Arthur Liu wrote:

On Mon, Sep 20, 2010 at 12:47 PM, Adrian von Bidder
  wrote:
>  Hi Arthur,
>
>  On Monday 20 September 2010 11.37:04 Obey Arthur Liu wrote:
>  [GSoC report]
>
>  Hmm.  It would have been nice to hear about what the students did and how
>  far they got in their GSoC projects instead of what they did at DC10.

The report is an aggregation of joint reports from students and
mentors ([1]). I combined and posted what I received. Some pairs
didn't send me their blurbs on time, but I suppose that some students
being back to school already is a reason.

Note that I have complete data as part of official GSoC evaluations
but their content is private to mentors by GSoC rule, so I'm still
keeping tabs on things, don't worry :)
I do worry. Unless I'm missing something, this is not the fourth Debian 
GSoC, but the fifth, and again, it's hard to believe this SoC was 
reasonably useful. The report we get has some information on 7 projects, 
although 8 are supposed to have been successful, and as Adrian and 
Olivier mentioned, no project results in most cases. And what about the 
unsuccessful projects? Their faith may not be relevant for d-d-a, but 
not documenting what happened, perhaps somewhere else, will not help new 
Debian GSoC admins to start with a good understanding of the challenges.


I would recommend requiring candidate mentors to agree to share 
evaluations with GSoC admins, so admins can at least pick information on 
results when a report has to be made.


At its current scale, the summer of code is approximately equivalent to 
a potential indirect subsidy of 50 000 USD and a direct subsidy of 5000 
USD. 5000 may not be a lot, but if we don't have enough volunteers to 
complete missing administrative manpower, then we should be honest about 
it and ask for more involvement... instead of having a misleading tone 
of optimism in the report. Yes, the SoC is surely a positive thing for 
Debian, but considering the resources granted, I almost feel ashamed to 
see how modest the results have been so far. (Note that I have not 
extensively monitored the SoC. The results may be greater than I 
imagine, but this is worryingly non-obvious.)


I must still thank you for sending a report. My first reaction was 
"Finally", I am just disappointed by the content.



--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4c9b1153.3060...@gmail.com

Re: Debian ppa

[Roland Mas]

William Grant, 2010-09-23 16:31:57 +1000 :

[...]

> While Launchpad.net does not provide Debian PPAs, what prevents you from
> taking the Launchpad code, rebranding it, and running your own instance?

Based on a presentation given by Jonathan Lange (product strategist for
Launchpad) at LSM this summer, the Launchpad code was never *really*
intended to be run in other instances than launchpad.net.  It was
initially a “that would be nice” feature, but nobody really took some
time to do it, and it wasn't a constraint taken into account when
designing the evolutions.  The code was eventually made publicly
available after much nagging, but a friend of mine who tried installing
it ran away screaming, much like I initially ran away screaming when I
started fiddling with Sourceforge.  It took several years (and two
forks/renamings) to have *Forge packages that can actually be installed
with a reasonably low effort.

  Also, still according to Jonathan, there are several people working
full-time on Launchpad sysadmin at Canonical.  We at Debian don't have
that kind of resources.

> It does require some changes to work with Debian's suites, but that
> would be far easier than reimplementing all the functionality yourself.

  Given the above, I strongly doubt that.  Adding PPA-like functionality
to FusionForge *might* be easier, since we already have Alioth, but even
that would be a significant amount of work, if only to setup the
build-daemons for that new service.

Roland,
Source^WGForge^WFusionForge maintainer since summer of 2000 and
*still* not quite mad (or am I?).
-- 
Roland Mas

Bada, bada, ba-da-da-daaa, doudou, doudou, dou-dou-dou-dou-baaa.
  -- in Song without words #1 (Paul Leavitt)


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/8739t0g8g3@mirexpress.internal.placard.fr.eu.org

Re: Summary of CUT discussions (Was: unstable/testing/[pending/frozen/]stable)

[Mehdi Dogguy]

On 09/23/2010 09:00 AM, Lucas Nussbaum wrote:
> 
> Raphael's article is now published, and is probably a good basis for
>  discussing CUT on -de...@. Free link: 
> http://lwn.net/SubscriberLink/406301/bd522adc828b3461/
> 

It's still looks weired to me to have to read this article there (I
mean, _only_ there). Can't it just be on CUT's website, or on the wiki?

-- 
Mehdi Dogguy مهدي الدڤي
http://dogguy.org/


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4c9b1280.3040...@dogguy.org

Re: Debian ppa

[William Grant]

On Thu, 2010-09-23 at 10:36 +0200, Roland Mas wrote:
> William Grant, 2010-09-23 16:31:57 +1000 :
> 
> [...]
> 
> > While Launchpad.net does not provide Debian PPAs, what prevents you from
> > taking the Launchpad code, rebranding it, and running your own instance?
> 
> Based on a presentation given by Jonathan Lange (product strategist for
> Launchpad) at LSM this summer, the Launchpad code was never *really*
> intended to be run in other instances than launchpad.net.  It was
> initially a “that would be nice” feature, but nobody really took some
> time to do it, and it wasn't a constraint taken into account when
> designing the evolutions.  The code was eventually made publicly
> available after much nagging,

Indeed. I was behind a lot of said nagging.

> but a friend of mine who tried installing
> it ran away screaming,

The instructions aren't quite so bad any more (see
https://dev.launchpad.net/Running). I've run Debian PPAs locally. It's
still not trivial to install on Debian, but it's close. Getting from a
running development Launchpad instance to one that can build packages is
also a reasonably well documented process
(https://dev.launchpad.net/Soyuz/HowToUseSoyuzLocally)

> much like I initially ran away screaming when I
> started fiddling with Sourceforge.  It took several years (and two
> forks/renamings) to have *Forge packages that can actually be installed
> with a reasonably low effort.
> 
>   Also, still according to Jonathan, there are several people working
> full-time on Launchpad sysadmin at Canonical.  We at Debian don't have
> that kind of resources.

Well, those few sysadmins manage Launchpad, Landscape, Ubuntu One and
some other internal applications. And you wouldn't want or need to run
all of Launchpad's services.

> > It does require some changes to work with Debian's suites, but that
> > would be far easier than reimplementing all the functionality yourself.
> 
>   Given the above, I strongly doubt that.  Adding PPA-like functionality
> to FusionForge *might* be easier, since we already have Alioth, but even
> that would be a significant amount of work, if only to setup the
> build-daemons for that new service.

Getting a local Launchpad instance to build Debian PPAs isn't hard. I
did it in an afternoon last year as an experiment. Setting it up in
production is a little harder, sure.

William
(Launchpad contributor, normally hacking on PPAs... I don't think I'm
entirely mad yet)


signature.asc
Description: This is a digitally signed message part

Re: Summary of CUT discussions (Was: unstable/testing/[pending/frozen/]stable)

[Lucas Nussbaum]

On 23/09/10 at 10:40 +0200, Mehdi Dogguy wrote:
> On 09/23/2010 09:00 AM, Lucas Nussbaum wrote:
> > 
> > Raphael's article is now published, and is probably a good basis for
> >  discussing CUT on -de...@. Free link: 
> > http://lwn.net/SubscriberLink/406301/bd522adc828b3461/
> > 
> 
> It's still looks weired to me to have to read this article there (I
> mean, _only_ there). Can't it just be on CUT's website, or on the wiki?

I agree that it's weird and suboptimal. I would have prefered to have it
mailed to -devel@, so we could reply and quote it easily. But there are
probably copyright transfer issues.

- Lucas


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100923090607.ga30...@xanadu.blop.info

Re: Summary of CUT discussions (Was: unstable/testing/[pending/frozen/]stable)

[Raphael Hertzog]

On Thu, 23 Sep 2010, Mehdi Dogguy wrote:
> On 09/23/2010 09:00 AM, Lucas Nussbaum wrote:
> > 
> > Raphael's article is now published, and is probably a good basis for
> >  discussing CUT on -de...@. Free link: 
> > http://lwn.net/SubscriberLink/406301/bd522adc828b3461/
> > 
> 
> It's still looks weired to me to have to read this article there (I
> mean, _only_ there). Can't it just be on CUT's website, or on the wiki?

Once the article is freely available on LWN (and not for subscribers
only), I can do whatever I want with the article. At that time, people
should be free to put it on the wiki.

I would like to thank LWN.net for allowing us to publish at least
a free subscriber link on this list so that interested people
not subscribed at LWN can read it and participate in the discussions.

Feel free to copy/paste extracts as well if you want to comment on a
specific part.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer ◈ [Flattr=20693]

Follow my Debian News ▶ http://RaphaelHertzog.com (English)
  ▶ http://RaphaelHertzog.fr (Français)


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100923091547.ga28...@rivendell.home.ouaza.com

Re: A new Priority level, ‘ backports ’ ? (Re: unstable/testing/[pending/frozen/]stable)

[Julien Cristau]

On Thu, Sep 23, 2010 at 17:12:49 +0900, Charles Plessy wrote:

> Le Thu, Sep 23, 2010 at 09:17:02AM +0200, Joerg Jaspert a écrit :
> > 
> > So what backports "priority" actually says is "my package is such a
> > bullshit that I don't want it ever released, but I am fine with putting
> > burden on the people keeping backports running instead". I think we have
> > a way already dealing with this: Don't upload them.
> 
> These packages are not that bad, since the FTP team accepted them…
> 
As far as I can tell the FTP team bases its accept/reject decisions on
whether it's legal for us to distribute a package (and whether it's
suitable for the component it was uploaded to in terms of the dfsg), not
whether it's a good idea to put that package in the distribution.

Cheers,
Julien


signature.asc
Description: Digital signature

Re: unstable/testing/[pending/frozen/]stable

[Raphael Hertzog]

Hi,

On Wed, 22 Sep 2010, Yaroslav Halchenko wrote:
> hm... did you mean
> http://lwn.net/Articles/406301/
> "A constantly usable testing distribution for Debian"?

Yes.

> if indeed, taken on the reasoning that "testing" is a bad name and "rolling" 
> is
> better, then it goes similar to what I saw behind 'constatly present'
> testing up to replacing rolling -> testing ->[removal of packages] -> frozen

Well, summarizing the whole with a few arrows is difficult but note that
the current rolling proposal is more like this:

Outside of freeze:
--
unstable → testing → rolling
   ↑
targetted uploads

During freeze:
--
t-p-u→ testing  
 ↗ (not automatic)
unstable → rolling
 ↑
 targetted uploads

> now about 'pending': following description confused me quite a bit:
> 
> ... during a freeze, testing is no longer automatically updated, which
> makes it inappropriate to feed the rolling distribution. That's why rolling
> would be reconfigured to grab updates from unstable (but using the same rules
> as testing).
> 
> But unstable remains to serve as the entry point to feed frozen testing as
> well, so with absent other entry-point (pending in my scenario) there is a
> conflict -- I can't upload 1 version which I intend to get to frozen testing
> and another one to get into rolling (experimental obviously can't serve as
> such).  or it all would go through an addendum (*-proposed-updates)?

That entry point aleady exists and is called testing-proposed-updates
indeed.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer ◈ [Flattr=20693]

Follow my Debian News ▶ http://RaphaelHertzog.com (English)
  ▶ http://RaphaelHertzog.fr (Français)


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100923092730.gb28...@rivendell.home.ouaza.com

Re: Re: Google Summer of Code 2010 Debian Report

[Obey Arthur Liu]

On Thu, Sep 23, 2010 at 10:35 AM, Filipus Klutiero  wrote:
>  Obey Arthur Liu wrote:
>>
>> On Mon, Sep 20, 2010 at 12:47 PM, Adrian von Bidder
>>   wrote:
>> >  Hi Arthur,
>> >
>> >  On Monday 20 September 2010 11.37:04 Obey Arthur Liu wrote:
>> >  [GSoC report]
>> >
>> >  Hmm.  It would have been nice to hear about what the students did and
>> > how
>> >  far they got in their GSoC projects instead of what they did at DC10.
>>
>> The report is an aggregation of joint reports from students and
>> mentors ([1]). I combined and posted what I received. Some pairs
>> didn't send me their blurbs on time, but I suppose that some students
>> being back to school already is a reason.
>>
>> Note that I have complete data as part of official GSoC evaluations
>> but their content is private to mentors by GSoC rule, so I'm still
>> keeping tabs on things, don't worry :)
>
> I do worry. Unless I'm missing something, this is not the fourth Debian
> GSoC, but the fifth, and again, it's hard to believe this SoC was reasonably
> useful. The report we get has some information on 7 projects, although 8 are
> supposed to have been successful, and as Adrian and Olivier mentioned, no
> project results in most cases. And what about the unsuccessful projects?
> Their faith may not be relevant for d-d-a, but not documenting what
> happened, perhaps somewhere else, will not help new Debian GSoC admins to
> start with a good understanding of the challenges.
>
> I would recommend requiring candidate mentors to agree to share evaluations
> with GSoC admins, so admins can at least pick information on results when a
> report has to be made.

Mentors are usually restricted by their spare time. Remember that
contrary to students, they usually have an actual job.
I do not think that we need a constraining agreement with mentors on
that point. They would usually happily do it.

> At its current scale, the summer of code is approximately equivalent to a
> potential indirect subsidy of 50 000 USD and a direct subsidy of 5000 USD.
> 5000 may not be a lot, but if we don't have enough volunteers to complete
> missing administrative manpower, then we should be honest about it and ask
> for more involvement... instead of having a misleading tone of optimism in

Breaking news: people are welcome to help out for managing the Summer
of Code at Debian. There's plenty of work to do, even outside of the
summer period. (This is serious.)

> the report. Yes, the SoC is surely a positive thing for Debian, but
> considering the resources granted, I almost feel ashamed to see how modest
> the results have been so far. (Note that I have not extensively monitored
> the SoC. The results may be greater than I imagine, but this is worryingly
> non-obvious.)

I think the issue is that you're confusing Summer of Code participants
with paid consultants. They are not. They are just students, most
often newbies at free software, whose summer happen to have been
cleared out of another summer job by the GSoC stipend. As such, you
should have similar survival rate expectations for a Debian GSoC
project as for any other Debian project that you or any DD would
happen to be working on. Perhaps a bit higher, but not much.

Regarding projects management, well, if you expect a level of
accountability on par with what you'd have in a business, then you
need to have the appropriate management manpower, and perhaps more
importantly, a particular professional mindset from mentors and
students. These are not the usual way Debian operates, which is what
makes it difficult.

I plan to run a BoF with fellow admins and mentors from other
organizations at the Mentors Summit to deal with these management and
reporting aspects. I'll make sure to tell you how it goes.

> I must still thank you for sending a report. My first reaction was
> "Finally", I am just disappointed by the content.

You're welcome.

Arthur


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/aanlkti=oxtu5f0qmzsw2k0fcyudhteg-9tjeoxjvr...@mail.gmail.com

Re: Google Summer of Code 2010 Debian Report

[Bastian Venthur]

Am 22.09.2010 08:56, schrieb Olivier Berger:
> Le lundi 20 septembre 2010 à 12:47 +0200, Adrian von Bidder a écrit :
>> Hi Arthur,
>>
>> On Monday 20 September 2010 11.37:04 Obey Arthur Liu wrote:
>> [GSoC report]
>>
>> Hmm.  It would have been nice to hear about what the students did and how 
>> far they got in their GSoC projects instead of what they did at DC10.
>>
> 
> +1
> 
> I'd have been pleased to get some update about "Debbugs Bug Reporting
> and Manipulation API" too... any pointer ?

Will do as soon as I worked out the integration of the patch into
debbugs with Don.


Cheers,

Bastian

-- 
Bastian Venthur  http://venthur.de
Debian Developer venthur at debian org



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/i7f8mp$3k...@dough.gmane.org

Re: Summary of CUT discussions (Was: unstable/testing/[pending/frozen/]stable)

[Luk Claes]

On 09/23/2010 09:00 AM, Lucas Nussbaum wrote:
> On 22/09/10 at 15:01 +0200, Raphael Hertzog wrote:
>> Hi all,
>>
>> On Tue, 21 Sep 2010, Yaroslav Halchenko wrote:
>>> CUT discussions at debconf10 and recent news of the birth of Linux Mint
>>
>> discussions on CUT have continued after debconf on the CUT mailing. I
>> wrote a summary of the discussion that will be published in Linux Weekly
>> News before tomorrow.
>>
>> Hopefully this summary will then lead to a constructive discussion on the
>> way forward.
> 
> Hi,
> 
> Raphael's article is now published, and is probably a good basis for
> discussing CUT on -de...@.
> Free link: http://lwn.net/SubscriberLink/406301/bd522adc828b3461/

Personally I have the feeling that if we would choose for rolling as
described in the article, that testing would actually get replaced by
rolling and we do not care about extensive architecture support anymore.
Not sure if we want to take that route. Personally I think we are
already taking the necessary steps to have a nice compromise regarding
architecture support as well as most removals. Certainly there are
improvements possible, though I'd rather have them implemented in
testing proper (even if we would rename testing ;-)).

Regarding the snapshots, I think that unless they are not frequent (aka
one about every 6 months) we'd better spend our energy on more frequent
d-i releases and just promote the use of testing more. If the snapshots
would not be frequent they could probably help the general release
process, be a better service to many users and maybe even help to solve
the problems we have with clamav and chromium related packages.

Cheers

Luk


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4c9b353c.8070...@debian.org

Re: Summary of CUT discussions (Was: unstable/testing/[pending/frozen/]stable)

[Raphael Hertzog]

Hi Luk,

thanks for your comment!

On Thu, 23 Sep 2010, Luk Claes wrote:
> > Raphael's article is now published, and is probably a good basis for
> > discussing CUT on -de...@.
> > Free link: http://lwn.net/SubscriberLink/406301/bd522adc828b3461/
> 
> Personally I have the feeling that if we would choose for rolling as
> described in the article, that testing would actually get replaced by
> rolling and we do not care about extensive architecture support anymore.
> Not sure if we want to take that route. Personally I think we are

The article describes the broad range of possibilities. But I agree that
it would be bad to pick the extreme choice where rolling only
takes into account the mainstream architectures. I think it's safe
to keep that restriction for installation media made available on
snapshots but rolling itself should be consistent with testing in terms of
architecture support.

Given this, it means rolling becomes a superset of testing outside of
freeze, and a replacement for testing during the freeze. I would suggest
to start that way to not disturb the processes in places, but in the long
term I agree it should supersede testing. testing would be a branch of
rolling that starts at freeze time. This branch could then remove the
packages that are not deemed safe for a long term release.

> already taking the necessary steps to have a nice compromise regarding
> architecture support as well as most removals. Certainly there are
> improvements possible, though I'd rather have them implemented in
> testing proper (even if we would rename testing ;-)).

I would like this if it were possible. But I'm not sure how to achieve it.

How can we ensure that testing always contains a stable version of
chromium ? The current decision of keeping it out of testing was right
given our actual constraints on what's ok for a stable release.
I would argue that we need to redefine our criteria for a stable release
and I plan to have this discussion at some point but I think in the mean
time having rolling is good way to fix this.

How can we ensure that testing continues to be updated during
freeze time ? This one is really not fixable without a second
distribution. I know it's also the most problematic aspect for the release
team because you fear that it will make people care less about getting a
stable release out of the door. I think this fear is not completely
justified, people that do not care do not need an excuse to not care, they
already do it (unfortunately).

> Regarding the snapshots, I think that unless they are not frequent (aka
> one about every 6 months) we'd better spend our energy on more frequent
> d-i releases and just promote the use of testing more. If the snapshots
> would not be frequent they could probably help the general release
> process, be a better service to many users and maybe even help to solve
> the problems we have with clamav and chromium related packages.

Why would non-frequent snapshots help more than frequent snapshots?

Why do you believe that those snapshots would not be d-i releases in some
ways?

Personally I would like to have snapshots every 2 or 3 months. Colin
Watson pointed out in an LWN comment (http://lwn.net/Articles/406597/):
| There's a good chance that CUT could serve a dual purpose of making it
| easier to prepare new stable releases. As many projects have found, if you
| have more-or-less releaseable checkpoints every so often then it's easier
| to prepare a better-than-usual one for your gold release.

And I agree with him in general. By officially endorsing a constantly
usable rolling distribution, it's clear to everybody that what goes in
unstable should always be in a releasable state. And if the regular CUT
snapshot provide motivations to the d-i team to produce a release because
it will be immediately used, it's a benefit for the whole stable release
process. I'm sure some people will call this a pipe dream, but at the very
least, this whole project supports that ideal and we really do not want to
make it more difficult to get a stable release out. We just want to offer
something else for other kind of users that we're currently not serving
as well as we could.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer ◈ [Flattr=20693]

Follow my Debian News ▶ http://RaphaelHertzog.com (English)
  ▶ http://RaphaelHertzog.fr (Français)


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100923123030.gc31...@rivendell.home.ouaza.com

Bug#597839: ITP: emerald-themes -- Themes for Emerald Window Decorator

[Janos Guljas]

Package: wnpp
Severity: wishlist
Owner: Janos Guljas 

* Package name: emerald-themes
  Version : 0.6.0
  Upstream Author : Quinn Storm 
* URL : http://cgit.compiz.org/fusion/decorators/emerald-themes/
* License : GPL
  Description : Themes for Emerald Window Decorator

This package provides additional themes for Emerald.

Hi,

I intend to package Emerald Window Decorator #522935, so emerald-themes
would be nice to have too.

Best,
Janos



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20100923131619.12895.78460.report...@mac.resenje.org

Re: recovering from compromised keys

[Simon McVittie]

(Context: a private mail to which I'm replying suggested that full-disk
encryption should be used to make it harder to subvert our infrastructure,
and worried about the use of an unencrypted /boot, since "they" could
insert a keylogger or trojan into the initrd.)

By policy, we use full-disk encryption at my workplace (where full-disk
really means "except the bootloader and /boot"). For a 2-year-old recipe for
it, which I believe still mostly works with grub2, see
http://smcv.pseudorandom.co.uk/2008/09/cryptroot/

Needing an unencrypted /boot just means you have to distrust /boot after you
lose and then regain control of your laptop. The secrets in the encrypted part
are still inaccessible, until or unless you enter your passphrase into the
compromised /boot.

If you assume that "they" haven't tampered with your BIOS or hardware and
put a keylogger *there*, you can fix this situation with full tin-foil-hat
compliance, if you've taken then precaution of having an always-up-to-date
copy of /boot in the encrypted area. To do so, boot from removable media,
access the encrypted area, overwrite the possibly-compromised /boot with the
backup, and reinstall the bootloader and MBR.

Simon


signature.asc
Description: Digital signature

not yet, Re: debdelta back online

[A Mennucc]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Il 22/09/2010 22:46, A Mennucc ha scritto:
> due to my PC running out of disk space, no deltas were generated in the
> last week

It seems that there was another problem: there is broken pdiff in
amd64/experimental, so that debmirror was not updating my local repository

now it should be working (but it will take some time to create all deltas)

a.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkybY6oACgkQ9B/tjjP8QKT58QCfafIdRgSitqH4l5cNOXpdTxEb
Le0An3wFK0x7XDMmyhxZP8o5dtFAPNMw
=iEGe
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4c9b63aa.10...@debian.org

Re: A new Priority level, ‘backports’ ? (R e: unstable/testing/[ pending/frozen/]stabl e)

[Marc Haber]

On Thu, 23 Sep 2010 11:23:55 +0200, Julien Cristau
 wrote:
>As far as I can tell the FTP team bases its accept/reject decisions on
>whether it's legal for us to distribute a package (and whether it's
>suitable for the component it was uploaded to in terms of the dfsg), not
>whether it's a good idea to put that package in the distribution.

The ftp team has a history of strongly discouraging uploads that they
don't feel like accepting (such as a package that would download
eicar.com from the internet and place it in a defined place where
other packages might find and use it) and of killing of packages on
grounds that "nobody sane would use them", such as clamav-data, which
force-died in the course of volatile moving under the ftp team's
reign.

Greetings
Marc
-- 
-- !! No courtesy copies, please !! -
Marc Haber |   " Questions are the | Mailadresse im Header
Mannheim, Germany  | Beginning of Wisdom " | http://www.zugschlus.de/
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/e1oynah-0005ue...@swivel.zugschlus.de

Re: debdelta back online

[A Mennucc]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Il 23/09/2010 08:59, Javier Fernandez-Sanguino ha scritto:
> On 22 September 2010 22:46, A Mennucc  wrote:
>> due to my PC running out of disk space, no deltas were generated in the
>> last week (while I was absent); I found more space, so it will be back
>> online as soon as it generates all needed deltas.
> 
> Question: How much space does debdelta take? (per architecture?)

currently I am creating deltas for amd64 and i386, and for
lenny squeeze sid experimental ;
there are ~14000 deltas  , the total size of deltas is ~ 9Gbytes .

I also create deltas for lenny-security, those are ~ 5GByte .

To create deltas, I need a local mirror of the above suites, and that is
quite big nowadays .

> You
> might need to provide figures if you want some "big Debian server" to
> host this service...

the discussion about this is in http://bugs.debian.org/548709 ;
it stalled for some time, but now Joerg is helping me

a.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkybZh8ACgkQ9B/tjjP8QKQqtwCfQ+zeXv9JCFj8TIfT/zQKToiX
D0MAn2Dvnc8kDE4GFla8MMoNrgqUR3uE
=FFGo
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4c9b661f.8060...@debian.org

Re: recovering from compromised keys

[Osamu Aoki]

On Thu, Sep 23, 2010 at 03:13:06PM +0100, Simon McVittie wrote:
...
> By policy, we use full-disk encryption at my workplace (where full-disk
> really means "except the bootloader and /boot"). For a 2-year-old recipe for
> it, which I believe still mostly works with grub2, see
> http://smcv.pseudorandom.co.uk/2008/09/cryptroot/

Can we maintain suspend/resume type-features with such configuration?

Unless we use unencrypted swap, it seems we have to give up
suspend/resume.  Then we a bit of loose security 

How people cope with this on laptop ... I am curious.

Osamu


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100923145026.ga5...@debian.org

Re: recovering from compromised keys

[Mike Hommey]

On Thu, Sep 23, 2010 at 11:50:26PM +0900, Osamu Aoki wrote:
> On Thu, Sep 23, 2010 at 03:13:06PM +0100, Simon McVittie wrote:
> ...
> > By policy, we use full-disk encryption at my workplace (where full-disk
> > really means "except the bootloader and /boot"). For a 2-year-old recipe for
> > it, which I believe still mostly works with grub2, see
> > http://smcv.pseudorandom.co.uk/2008/09/cryptroot/
> 
> Can we maintain suspend/resume type-features with such configuration?
> 
> Unless we use unencrypted swap, it seems we have to give up
> suspend/resume.  Then we a bit of loose security 
> 
> How people cope with this on laptop ... I am curious.

You only need to give up *randomized* swap encryption. You can still
have an encrypted swap, you just can't use a random key.

Mike


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100923151401.ga7...@glandium.org

Re: recovering from compromised keys

[Roland Mas]

Mike Hommey, 2010-09-23 17:14:01 +0200 :

> On Thu, Sep 23, 2010 at 11:50:26PM +0900, Osamu Aoki wrote:
>> On Thu, Sep 23, 2010 at 03:13:06PM +0100, Simon McVittie wrote:
>> ...
>> > By policy, we use full-disk encryption at my workplace (where full-disk
>> > really means "except the bootloader and /boot"). For a 2-year-old recipe 
>> > for
>> > it, which I believe still mostly works with grub2, see
>> > http://smcv.pseudorandom.co.uk/2008/09/cryptroot/
>> 
>> Can we maintain suspend/resume type-features with such configuration?
>> 
>> Unless we use unencrypted swap, it seems we have to give up
>> suspend/resume.  Then we a bit of loose security 
>> 
>> How people cope with this on laptop ... I am curious.
>
> You only need to give up *randomized* swap encryption. You can still
> have an encrypted swap, you just can't use a random key.

Indeed.  My current setup is that sda1 is small, unencrypted and holds
/boot only.  sda2 is the whole rest of the hard disk, and it's mapped to
a LUKS device used as a physical volume for LVM, and there are several
LVs on there, including those mounted as filesystems and one for swap.

Roland.
-- 
Roland Mas

Au royaume des aveugles, il y a des borgnes à ne pas dépasser.
  -- in Soeur Marie-Thérèse des Batignoles (Maëster)


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/87lj6seask@mirexpress.internal.placard.fr.eu.org

Re: recovering from compromised keys

[Simon McVittie]

On Thu, 23 Sep 2010 at 17:31:39 +0200, Roland Mas wrote:
> Indeed.  My current setup is that sda1 is small, unencrypted and holds
> /boot only.  sda2 is the whole rest of the hard disk, and it's mapped to
> a LUKS device used as a physical volume for LVM, and there are several
> LVs on there, including those mounted as filesystems and one for swap.

That's the configuration we use too. Suspend-to-disk works fine; you're
prompted for a passphrase by the initramfs, which then decrypts and sets up
the LVM blob, and resumes from there.

Suspend-to-RAM also works, but is obviously not secure against attackers
waking up the laptop and exploiting some bug in a locked screensaver, or
remote access, or whatever.

 S


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20100923160755.ga29...@reptile.pseudorandom.co.uk

Re: Summary of CUT discussions (Was: unstable/testing/[pending/frozen/]stable)

[Michael Gilbert]

On Thu, 23 Sep 2010 14:30:30 +0200, Raphael Hertzog wrote:
> Personally I would like to have snapshots every 2 or 3 months. Colin
> Watson pointed out in an LWN comment (http://lwn.net/Articles/406597/):
> | There's a good chance that CUT could serve a dual purpose of making it
> | easier to prepare new stable releases. As many projects have found, if you
> | have more-or-less releaseable checkpoints every so often then it's easier
> | to prepare a better-than-usual one for your gold release.
> 
> And I agree with him in general. By officially endorsing a constantly
> usable rolling distribution, it's clear to everybody that what goes in
> unstable should always be in a releasable state. 

There are of course a couple large downsides to this.  It becomes next
to impossible to make big/interesting changes across the distribution,
and developers will be forced (due to the short time frame) into being
very conservative with their uploads. Today, maintainers have the
important freedom to make big changes at the beginning of the release
cycle knowing that they have over a year to fix any resulting
problems, and I think it would be a shame to take that away.

I view testing snapshots more as a preview for a very limited subset of
users; the type that are looking for rather fresh software and would be
perfect candidates for testing, but they aren't willing to deal with
the daily upgrade treadmill.  Again, I think this is a rather small
group of users.  Mosts users that fall into the "I need the latest
shiny" category are served fairly well by the existing testing.  They
just need a constantly working installer.

Best wishes,
Mike


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20100923135023.b45d5e7e.michael.s.gilb...@gmail.com

Re: Google Summer of Code 2010 Debian Report

[Filipus Klutiero]

 On 2010-09-23 05:32, Obey Arthur Liu wrote:

On Thu, Sep 23, 2010 at 10:35 AM, Filipus Klutiero  wrote:

[...]
I would recommend requiring candidate mentors to agree to share evaluations
with GSoC admins, so admins can at least pick information on results when a
report has to be made.

Mentors are usually restricted by their spare time. Remember that
contrary to students, they usually have an actual job.
Which is why I'm suggesting that admins get allowed to use their 
reports, so if any individual mentor is too busy to give a report on the 
results and the students also fails to do it, the admins will be able to 
do it easily.

I do not think that we need a constraining agreement with mentors on
that point. They would usually happily do it.

...then why did most of them fail to do it here :-?

At its current scale, the summer of code is approximately equivalent to a
potential indirect subsidy of 50 000 USD and a direct subsidy of 5000 USD.
5000 may not be a lot, but if we don't have enough volunteers to complete
missing administrative manpower, then we should be honest about it and ask
for more involvement... instead of having a misleading tone of optimism in

Breaking news: people are welcome to help out for managing the Summer
of Code at Debian. There's plenty of work to do, even outside of the
summer period. (This is serious.)
I'm not sure I get exactly your intended message, but if this is 
serious, this is the kind of information that would be actually relevant 
on d-d-a next time the SoC team sends a mail there.

the report. Yes, the SoC is surely a positive thing for Debian, but
considering the resources granted, I almost feel ashamed to see how modest
the results have been so far. (Note that I have not extensively monitored
the SoC. The results may be greater than I imagine, but this is worryingly
non-obvious.)

I think the issue is that you're confusing Summer of Code participants
with paid consultants. They are not. They are just students, most
often newbies at free software, whose summer happen to have been
cleared out of another summer job by the GSoC stipend.
Heh, it would be hard to confuse SoC students with consultants when 
they're being paid 5000 USD for 12 weeks of works...

As such, you
should have similar survival rate expectations for a Debian GSoC
project as for any other Debian project that you or any DD would
happen to be working on. Perhaps a bit higher, but not much.
This hits an extremely interesting point. The reference to a "survival 
rate" betrays what I think is a major error GSoC administration has 
made. It seems the projects selected are in large part new projects, 
rather than improvements to existing software.


When projects are selected, admins need to keep in mind that those 
working on them are not professional and experienced developers, but 
students (who may not even study computer science). Furthermore, these 
students will have only 12 summer weeks, during which they'll work from 
home, most certainly away from the resources they need, with as only 
somewhat reliable guide their mentor, which may not even get 500 USD for 
the whole mentoring process. For these projects to survive, or even have 
a chance to be born, their scope needs to be very limited.


When giving a quick look at this year's projects, this problem seems to 
be a lot lesser than it has been in the past. However, this problem is 
in fact part of a wider one, the tendency to pick big projects. Of 
course, big projects are more attractive at first sight, but we're not 
that stupid. Even with a considerate selection, big projects are more 
interesting, because they should get more work done than a project which 
would possibly be completed before then end of summer.


But we must not forget a big advantage of smaller projects. Not only are 
their results more likely to be useful, but the fact that the students 
will have completed them is a good thing per se, because the SoC is also 
about recruiting future Debian contributors. As you must know, big 
project students always say they're going to complete the work after the 
end of the summer, but they're going back to school and obviously give 
up at some point, which leaves them with a feeling of guilt that will 
not help their perception of being further involved in Debian.


And in fact, this big project / small project division is in good part a 
false dichotomy. In reality, even if the project would be finished 
half-term, there is always room for improvement, and often surrounding 
things that can be done to make use of the project's results.


I'm stopping here, but mentioning that despite this, there *could* be 
ways to tackle big projects, like going in phases (something similar was 
tried already).

Regarding projects management, well, if you expect a level of
accountability on par with what you'd have in a business, then you
need to have the appropriate management manpower, and perhaps more
importantly, a particular professional mindse

Bug#597866: ITP: ukopp -- Full incremental backup to disk or disk-like device

[Alessio Treglia]

Package: wnpp
Severity: wishlist
Owner: Alessio Treglia 

* Package name: ukopp
  Version : 3.8
  Upstream Author : Michael Cornelison 
* URL : http://kornelix.squarespace.com/ukopp/
* License : GPL
  Programming Lang: C
  Description : Full incremental backup to disk or disk-like device

Ukopp is a program used to copy or back-up disk files to a disk or disk-like
device, such as a USB stick. It copies only new or modified files since the
last backup, and is therefore quite fast. A GUI is used to navigate the file
system to include or exclude files or directories at any level. These
choices can be saved in a job file for repeated use. New files appearing
within the included directories are handled automatically. Optionally,
previous versions of the backup files can be retained instead of being
overwritten. Files can be selectively restored using a GUI. Ownership and
permissions are also restored, even if the target device uses a Microsoft
file system.



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20100921114740.15059.91232.report...@alessio-laptop

Re: A new Priority level, ‘backports’ ? (Re: unstable/testing/[pending/frozen/]stable)

[Russ Allbery]

Marc Haber  writes:

> The ftp team has a history of strongly discouraging uploads that they
> don't feel like accepting (such as a package that would download
> eicar.com from the internet and place it in a defined place where other
> packages might find and use it) and of killing of packages on grounds
> that "nobody sane would use them", such as clamav-data, which force-died
> in the course of volatile moving under the ftp team's reign.

I completely support the FTP team's refusal to accept completely
automatically generated and automatically signed (unattended) packages in
the archive.

-- 
Russ Allbery (r...@debian.org)   


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87wrqcxcv2@windlord.stanford.edu

Bug#597899: ITP: yii-framework -- High-performance component-based PHP framework

[Paul McEnery]

Package: wnpp
Severity: wishlist
Owner: Paul McEnery 


* Package name: yii-framework
  Version : 1.1.4
  Upstream Author : Qiang Xue 
* URL : http://www.yiiframework.com
* License : BSD
  Programming Lang: PHP
  Description : High-performance component-based PHP framework

Yii is a high-performance component-based PHP framework best for developing
large-scale Web applications. Yii comes with a full stack of features,
including MVC, DAO/ActiveRecord, I18N/L10N, caching, jQuery-based AJAX support,
authentication and role-based access control, scaffolding, input validation,
widgets, events, theming, Web services, and so on. Written in strict OOP,
Yii is easy to use and is extremely flexible and extensible.

The name Yii (pronounced as Yee or [ji:]) stands for easy, efficient and 
extensible.



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100923232421.8926.4260.report...@localhost

Re: Backports service becoming official

[Don Armstrong]

On Thu, 23 Sep 2010, Joerg Jaspert wrote:
> Stepping in sideways here, but in case you can make use of them,
> backports is creating the same debversion info like the main
> archive. Want them synced to the bts?

Yes, please.


Don Armstrong

-- 
Whatever you do will be insignificant, but it is very important that
you do it.
 -- Mohandas Karamchand Gandhi

http://www.donarmstrong.com  http://rzlab.ucr.edu


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100923235908.gj6...@teltox.donarmstrong.com

Re: Google Summer of Code 2010 Debian Report

[David Kalnischkies]

2010/9/23 Filipus Klutiero :
>  On 2010-09-23 05:32, Obey Arthur Liu wrote:
>> On Thu, Sep 23, 2010 at 10:35 AM, Filipus Klutiero
>>  wrote:
>>>
>>> [...]
>>> I would recommend requiring candidate mentors to agree to share
>>> evaluations
>>> with GSoC admins, so admins can at least pick information on results when
>>> a
>>> report has to be made.
>>
>> Mentors are usually restricted by their spare time. Remember that
>> contrary to students, they usually have an actual job.
>
> Which is why I'm suggesting that admins get allowed to use their reports, so
> if any individual mentor is too busy to give a report on the results and the
> students also fails to do it, the admins will be able to do it easily.

Maybe, in this case you should also motivate the students to do the extra
work you expect from them. They all were required to fill in two rather
longish evaluations in the gsoc process - repeating the same again is,
lets say, boring. Given that we (as in students) prepared all a few debconf
slides relatively near the end of gsoc most of it is already said - even
by the respective student in person… (video is available).
And these slides should be better than the evaluations as these are rather
gsoc organizational orientated questions and not so much about the
project itself…


And more personal - as I don't know about the others and non-attending
debconf doesn't help a lot - I revised very few (as in no) "gimme more info"
requests, so writing a whole lot into the blue which is maybe never read
(or given that nobody requested it - very likely never read) isn't very
motivating - or at least I can find a bunch of more motivating tasks
including university stuff, helping my uncle making (and drinking) wine
or such boring things as fixing bugs or even writing emails…
(and yes, I have writing something on my todo list, just not high-priority)

>>> At its current scale, the summer of code is approximately equivalent to a
>>> potential indirect subsidy of 50 000 USD and a direct subsidy of 5000
>>> USD.
>>> 5000 may not be a lot, but if we don't have enough volunteers to complete
>>> missing administrative manpower, then we should be honest about it and
>>> ask
>>> for more involvement... instead of having a misleading tone of optimism
>>> in
>>
>> Breaking news: people are welcome to help out for managing the Summer
>> of Code at Debian. There's plenty of work to do, even outside of the
>> summer period. (This is serious.)
>
> I'm not sure I get exactly your intended message, but if this is serious,
> this is the kind of information that would be actually relevant on d-d-a
> next time the SoC team sends a mail there.

Come on, can you name even one team in debian (or any open source project)
which has too many active members? Being understaffed is the norm,
not something you need to mention explicitly in every mail you write…
(okay, this paragraph is a bit too depressive, but I am out of time to
reword it - at bit ironic in this context… ;) )


>>> the report. Yes, the SoC is surely a positive thing for Debian, but
>>> considering the resources granted, I almost feel ashamed to see how
>>> modest
>>> the results have been so far. (Note that I have not extensively monitored
>>> the SoC. The results may be greater than I imagine, but this is
>>> worryingly
>>> non-obvious.)
>>
>> I think the issue is that you're confusing Summer of Code participants
>> with paid consultants. They are not. They are just students, most
>> often newbies at free software, whose summer happen to have been
>> cleared out of another summer job by the GSoC stipend.
>
> Heh, it would be hard to confuse SoC students with consultants when they're
> being paid 5000 USD for 12 weeks of works...

You forget that the students have done a lot unpaid - choosing an
organization is nothing to be taken lightly. Further more you search
a proposal you find interesting - or even write your own, and that
for most students multiple times as the chance to be chosen is
higher then. Oh, and after choosing your proposal(s) you need to provide
your hopefully-soon-to-be organizations with a bunch of information
why you are the best student in the world. Searching and convincing
a mentor for your proposal especially if its your own can suck up
much time, too. But let us assume you have one and you are one of
the chosen ones (unlikely if you look at the numbers of students accepted
vs students applied in gsoc). Now begins something which Google calls
"Bonding time" - time in which you should dig (deeper) into your project,
get familiar with the source, read documentation meet your mentor and
your community and all this kind of stuff…
Reducing the gsoc to "3 months of writing code" you didn't give credit
to that pre-gsoc invest of the students as well as you dismiss the hidden
target: Encourage a student to use and work on the projects even after gsoc.
(which is for me the real and only target: but don't tell anyone)


>> As such, you
>> should have similar surviv

Bug#597903: ITP: gnome-gmail -- Make Gmail an option for the default GNOME mail handler

[David Steele]

Package: wnpp
Severity: wishlist
Owner: David Steele 


* Package name: gnome-gmail
  Version : 1.6
  Upstream Author : David Steele 
* URL : http://gnome-gmail.sourceforge.net/
* License : GPL
  Programming Lang: Python
  Description : Make Gmail an option for the default GNOME mail handler

This package makes Gmail a choice in the GNOME control panel for the default
mail handler. It opens in the default web browser.



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20100924015117.17964.45959.report...@daves-debian

Re: recovering from compromised keys

[Paul Wise]

On 9/24/10, Simon McVittie  wrote:

> Suspend-to-RAM also works, but is obviously not secure against attackers
> waking up the laptop and exploiting some bug in a locked screensaver, or
> remote access, or whatever.

Don't forget about folks using cold boot attacks to grab your key from
RAM. I also saw a paper somewhere about returning the system to a
running state after such attacks.

-- 
bye,
pabs

http://wiki.debian.org/PaulWise


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/aanlkti=4opxthdmave0fgipzpmez7a66+vd+p1if9...@mail.gmail.com

Re: Google Summer of Code 2010 Debian Report

[Filipus Klutiero]

 On 2010-09-23 21:26, David Kalnischkies wrote:

2010/9/23 Filipus Klutiero:

  On 2010-09-23 05:32, Obey Arthur Liu wrote:

On Thu, Sep 23, 2010 at 10:35 AM, Filipus Klutiero
  wrote:

[...]
I would recommend requiring candidate mentors to agree to share
evaluations
with GSoC admins, so admins can at least pick information on results when
a
report has to be made.

Mentors are usually restricted by their spare time. Remember that
contrary to students, they usually have an actual job.

Which is why I'm suggesting that admins get allowed to use their reports, so
if any individual mentor is too busy to give a report on the results and the
students also fails to do it, the admins will be able to do it easily.

Maybe, in this case you should also motivate the students to do the extra
work you expect from them. They all were required to fill in two rather
longish evaluations in the gsoc process - repeating the same again is,
lets say, boring. Given that we (as in students) prepared all a few debconf
slides relatively near the end of gsoc most of it is already said - even
by the respective student in person… (video is available).
And these slides should be better than the evaluations as these are rather
gsoc organizational orientated questions and not so much about the
project itself…
Really, if writing a paragraph on what you did during 12 weeks is 
significant extra work for you, I wonder why you bothered writing this 
reply.

And more personal - as I don't know about the others and non-attending
debconf doesn't help a lot - I revised very few (as in no) "gimme more info"
requests, so writing a whole lot into the blue which is maybe never read
(or given that nobody requested it - very likely never read) isn't very
motivating - or at least I can find a bunch of more motivating tasks
including university stuff, helping my uncle making (and drinking) wine
or such boring things as fixing bugs or even writing emails…
(and yes, I have writing something on my todo list, just not high-priority)
I don't think you really understand our concerns. Nobody talked about 
writing "a whole lot". We're disappointed that most project do not have 
*a single word* published on the results. There is room for a middle 
ground between a word and a whole lot.


Besides, I'm not talking about getting students to write this, but 
making sure there's an easy backup solution if they don't.

At its current scale, the summer of code is approximately equivalent to a
potential indirect subsidy of 50 000 USD and a direct subsidy of 5000
USD.
5000 may not be a lot, but if we don't have enough volunteers to complete
missing administrative manpower, then we should be honest about it and
ask
for more involvement... instead of having a misleading tone of optimism
in

Breaking news: people are welcome to help out for managing the Summer
of Code at Debian. There's plenty of work to do, even outside of the
summer period. (This is serious.)

I'm not sure I get exactly your intended message, but if this is serious,
this is the kind of information that would be actually relevant on d-d-a
next time the SoC team sends a mail there.

Come on, can you name even one team in debian (or any open source project)
which has too many active members? Being understaffed is the norm,
not something you need to mention explicitly in every mail you write…
(okay, this paragraph is a bit too depressive, but I am out of time to
reword it - at bit ironic in this context… ;) )


Read carefully - I was not sure I got Obey's message correctly. He wrote 
"Breaking news: [...] (This is serious.)"
If he means that [...] is seriously breaking news, I think my answer is 
appropriate.


If however "Breaking news" is sarcastic, and he means, as you say, that 
all teams welcome help, implying that asking for more involvement would 
be vain, then my answer is different:
Debian teams could be put on a spectrum of vitality. At one end, you 
have the security team, which just needs to keep a minimal manpower. At 
the other end, you have the vimim team, working on the next-generation 
beat-them-all text editor. The vimim team could be vacant for a decade 
without anyone noticing, however if an accident reduces the security 
team to a single person, that person needs to scream immediately and 
start recruiting new people before the funerals are over. Close to the 
critical end, you have the archive maintenance team, of which the 
breakage, although it would not cause an immediate threat to Debian, 
would severely affect development, making most other teams unproductive. 
I consider the GSoC admins on the side of the security team, not as 
critical as the archive maintenance team, but still a team whose 
performance is critical to the productivity of our GSoC project teams.

the report. Yes, the SoC is surely a positive thing for Debian, but
considering the resources granted, I almost feel ashamed to see how
modest
the results have been so far. (Note that I have not extensively monitored
the