[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

[Popcon-developers] Re: Reverting some popcon changes



[Bill Allombert]
>> Would it not be better to fix the problems instead of just removeing
>> the code?
> 
> Be my guest, then.

Will do, when I find time to it. :)

> Then do not commit the client side now. This just make the cron
> script uselessly complex for no purpose.

I commited the client side to avoid anyone else wasting time to
implement it (it has been requested a few times in BTS, and I believe
it is good to let those interested in that feature to see the results
directly in the package), and to increase the chance of someone
finding time to look at the server side.  Both reasons apper to be
purposes to include the code in the client to me.

Yes, it increases the complexity slightly, but we are talking about a
112 line shell script, so I believe the complexity is still within
control.

> Just use the woody package on woody, and the sarge one on sarge!

This is not an option, to get the debian-edu machines to report to the
debian-edu collector.  For this to work, the HTTP option in the later
packages is needed.

> This way we can expect that the 5620 reports with popcon 1.31 come
> from sid users, the 3011 reports with 1.28 from sarge users and the
> 490 unknown from woody users.

Well, you can not really know this at the moment.  There is probably a
strong correlation, but there are several exceptions as backports are
being used today.

At debconf, I talked with people expressing an interest in woody
backport of popcon (for example Martin-?ric Racine), and I assuered
them that at least I would do my best to make sure the popcon package
continued to work in both oldstable, stable and testing.

So I see the value in backporting popcon, and hope others do the same.

>> Do you have an URL to the bug report for this issue?  Is it fixed in
>> the ubuntu package?
> 
> No, I told it to you and three Ubuntu developpers. No answer so far.

Well, for my part it has drowned in my other email.  I suspect the
chances of getting the issue addressed increases significantly if the
issue is reported into ubuntus and debians bug tracking system.

> I explained you 3 times already, at least one ever before you made
> the changes. Direct to disk skip the sanity checking performed by
> prepop.pl.  This allows a specially crafted popcon submission to
> write to or create arbitrary files.

Ah, right.  That issue.  Sorry, but it was lost in my pile of mail
too, and I had forgotten it.  Did not seem like a major issue to me,
so I focused on other issues instead.  I'm implementing a simple fix
now, just piping the report through prepop.pl instead of writing
directly.

Reinserting popcon-developers on the CC list.  Your reply seemed to
have lost it, and I still believe we want to have the future plans for
popcon archived to have it available for the current and future
maintainers of the package.


Reply to: