On Sat, Jul 19, 2014 at 4:41 PM, intrigeri wrote:
> The Tails sources.{new,patches} still seem outdated. Is some part of
> the system not back up yet?
Due to the disk space issue and some IO stalls, DSA requested a new
machine from leaseweb. Last I checked that has been delivered, waiting
on zeroing the disks of the old machines before the new machines can
use the network ports currently in use by the old machines. Once that
is done I'll do another full run as a test and add it to cron if
successful.
> I could agree on this principle, but in practice, I doubt derivative
> developers explain in debian/changelog what part of their delta should
> be ignored ("legit" delta) and what should be improved. DEP-3's
> "Forwarded" field, when applicable, seems more adequate. Also,
> debian/changelog is not machine-readable, is meant to document
> incremental changes, and does not provide an aggregated view of the
> current state of things.
Good points, until now I expected people could work around that by
either contacting the origin of the changes or figuring it out
themselves.
> * Tails-specific packages: the information that should be easy to
> retrieve (ideally, in a machine-readable way) is "these packages
> are too specific to go into Debian (not mentioning the release
> cycle mismatch)". Even if we did add this information to
> debian/changelog, it would be quickly buried below dozens of other
> entries, and hard to find. Same for packages that are not really
> Tails-specific, but that can probably never be uploaded to Debian
> for legal reasons; same for packages that were removed for Debian
> (for good reasons) but are still needed in Tails.
These are new packages, they won't be presented to Debian people
anywhere right now, unless they look at sources.new. Someday I want to
do that, not sure about where/how though. When that happens I guess we
could define a debian/control field and or some heuristics about this.
> * modified packages: in general, ideally the relevant information
> should live in per-patch DEP-3 headers. Adding it to
> debian/changelog would duplicate information, in a way that's not
> easy to retrieve.
Agreed, however in general a lot of changes are to the contents of the
debian/ dir, so DEP-3 wouldn't work there, hmm.
> => I'm unconvinced that documenting this kind of things in
> debian/changelog's would help much. Not saying that our initial idea
> is the best possible one, though :) Thoughts, other ideas?
I was only suggesting that debian/changelog is currently the only
place for extra info about changes that derivatives use. Inventing
better mechanisms is definitely useful though.
> OK, created https://labs.riseup.net/code/issues/7608. Is there
> a meta-package or something to track such tasks in the Debian BTS?
> Alternatively, should I just add these ideas to
> https://wiki.debian.org/Derivatives/Integration#Ideas ? I've also
> found a list of FIXME's on top of the compare-source-package-list
> script, so I'm a bit confused.
So far there have been relatively few people working on the
derivatives census stuff and it was fairly experimental so a bug
tracker hasn't been needed; I've only used FIXMEs for code-related
things and the wiki page for ideas. Feel free to update the FIXMEs or
the wiki page. For now anything other than that seems like overkill to
me.
> In order to be able to graph things, it seems to me that one also need
> to know the date/time when a given version of a {new,modified} package
> was last seen in the derivative's APT repo. Would you happily take
> a patch against compare-source-package-list, that stores this
> information in sources.{new,patches}?
Sounds like a good idea to me.
Re patches in general: You can either send it to the list for review
or just commit if you're confident in the changes.
>> BTW: I plan to have a DebConf14 BoF about the derivatives
>> patch-generation stuff.
>
> Awesome. I'll be there.
Excellent, hopefully the hardware issues will be sorted by then :)
--
bye,
pabs
https://wiki.debian.org/PaulWise
