Re: DD's, Debian Mentors needs you!

[Niels Thykier]

Soren Stoutner:

After reading a number of comments to the email below, I thought I would
provide a bit of context for this email and Phil’s excellent work on Mentors.

Recently Phil has taken it upon himself to triage every package that requests
sponsorship on mentors.debian.net.  Here is an example of the work he does:

[...]


Hi,

I wholehearted agree that Phil is doing a lot of good work here and that 
it is helpful to all parties involved in d-mentors. From my PoV, what 
Phil does is so valuable that ideally we would provide it to all 
sponsored maintainers with minimal latency. For me, that means 
automating most of what Phil does. Ideally all, but I am not sure all 
the things Phil does are trivial to automate where we are now.




But I have found Phil’s work to be very helpful, as I have limited time to
handle sponsorships.  When I look at a package Phil has endorsed, I can be
sure that the simple and obvious things have already been taken care of.



Thinking a bit more on this and its long term sustainability, I think we 
have a spot here where we could automate the process a lot. If we look 
at the list of things Phil does:


 1. Build:

Automate-able if we had good sandboxes/throw away build machines.

 2. Lintian:

I think mentors.d.o already does this. But it only works on the
artifacts uploaded and Phil probably enriches this.

 3. Licenses:

While ideally, we would want this to be automatic, I think we do not
have a good solution to this and I doubt we get it any time soon.

Though an 80/20 might be in our grasp for someone interested and
I do not think it would need to depend on 1).

 4. Build Twice (sudo pbuilder build --twice .dsc):

Automate-able once 1) is solved.

 5. Reproducible builds (reporotest):

Trivially automate-able once 1) is solved.

 6. Install/Upgrade:

It sounds like something piuparts would check, so I assume this is
all solvable once 1) is complete.

 7. Curating packages that pass these checks to various prospective
sponsors (such as the mail we are all replying to)

These automations would not replace Phil since Phil in "failure" cases 
provides suggestions on how to move forward. This part we would ideally 
automate as well, but that is a much harder problem for most of these 
checks. Still, having a "red/green" marker would enable newcomers to 
figure out where they need more effort or assistance.


The salsa-CI pipeline basically does most of these (3+7 being very clear 
exceptions, do not remember if 4 is covered by salsa-ci, but adding it 
would probably easy) and that infrastructure already has "no trust" code 
execution flows. Another alternative might be leveraging debusine if 
that can do the same and is intended for this purpose (did not check).


In theory, we can reduce this to a already solved problem by linking the 
RFS/mentors entry with the relevant CI pipeline report where possible 
and a "Consider using the salsa-CI pipeline" check. Might need 
tag2upload or dgit (assuming these support mentors.d.o), since that 
would make the commit visible. Additional bells and whistles can be 
added to the salsa-CI pipeline in the form of a small machine readable 
report output that mentors.d.n could render if necessary (etc.)


I do think it could be a major improvement our sponsorship work flow for 
both sponsors and sponsored maintainers.


 1) We promote a streamlined packaging workflow that a large portion of
Debian already follows and leverage existing infrastructure. Any
updates to our workflow would appear into the sponsor workflow
checklist workflow because they are the same underlying checks.

 2) The workflow provides most of these checks with low latency
automation and would save the sponsored maintainers RFS +
mentors.d.o upload round trips.

 3) The process would be a lot more sustainable, since most of it would
be automatic.

Obviously, on paper is doable but it might require ironing out a lot of 
bends or even not be possible at all. Sadly, I am not volunteering to do 
it (got too much on my plate already). However, I am putting the idea 
out there in case someone has time and interest in working on this area.


I think the primary risk (problem to solve) is linking the mentors.d.o 
upload to a git commit on salsa and the related pipeline data for that. 
As said, I hope tag2upload/dgit could be part of the solution here (not 
sure how those will cope with mentors.d.o versions being a lot more 
mutable than regular uploads). For everything else, I think most of the 
heavy lifting have already been done and "just" a matter of gluing it 
all together.



I would heartily hope that Phil continues to send periodic emails to debian-
devel with lists of packages that he considers ready, but that are languishing
on the vine because nobody has noticed them.


Agreed.


[...] There is probably nothing as demotivating to a first-time
contributor as putting a lot of effort into a pack

Re: Produce extra build artifacts during package builds

[Niels Thykier]

Simon McVittie:

On Fri, 02 Aug 2024 at 16:40:15 +0900, Mattia Rizzolo wrote:

[...]



  * decide on a directory name (`./debian/export_artifacts/`?)
  * the build process will dump any files that could be interesting to
export in there (no decision if/how to define the structure within
this directory)
* potentially, all `dh_*` could copy there whatever is relevant to
  them (i.e., `dh_auto_configure` could export configure logs,
  `dh_auto_test` the various test logs, ..)


My concern about this, and the reason my prototype doesn't work this way,
is what I said in
.

The artifacts that I'm primarily interested in are the results of failed
testing, because at the moment librsvg and gtk4 have to exfiltrate
their failed test results (some of which are in the form of images,
because these are GUI libraries) by uuencoding PNG files and writing
the result to the log, and that's both inconvenient and inefficient.

But, when a test has failed, writing arbitrary imperative code to gather
up the package-specific results (for example the images that were generated
by the gtk4 test suite) is extra complexity for the package maintainer,
which can have bugs, and is rarely tested because hopefully the tests
usually pass. I dislike that as a pattern, and I'd strongly prefer a
declarative syntax of some sort.

(Take a look at all the ad-hoc scripting that src:gtk4 has around what
to do after test failures and I think you'll see what I mean!)



I agree with Simon on this part. This logic will rarely be tested by the 
maintainer, so we should minimize the amount of code a maintainer should 
do for this.


Thanks to previous design work, I think this problem is now largely down 
to various tool writers (pbuilder/sbuilder + the build helper tooling) 
doing a prototype of it and letting it loose.



In the design that I prototyped, it's declarative, loosely inspired by
the equivalent Gitlab-CI feature:

- the maintainer can write patterns into debian/build-artifacts for
   package-specific quirks like GTK's reftests
   (#-prefixed comments are allowed)


I am a bit tempted to keep this one out of the spec and leave it to the 
build-helper to define it. I find that files in `debian/` are not very 
discoverable and they are harder to support properly in tooling like 
`debputy lsp server`. Each file format requires extra setup and there is 
not a good way to announce they exist unlike fields in `debian/control`. 
 For `debputy` based packages, I would prefer to have this in the 
`debian/debputy.manifest`, since that will enable me to guide the 
packager to its existence and provide on-line documentation for it.



- tools like debhelper can append patterns to debian/extra-build-artifacts,
   for example dh_auto_* in Meson mode should append "obj-*/meson-logs/*"


As a minor detail, I would make this a .d directory where tools can 
write files in. This avoids issues with concurrency control. It is 
possible to run `dh_auto_configure` in parallel. That is not the only 
way concurrency issues could happen and I am already not excited about 
solving concurrency issues even assuming debhelper is the only source of 
this problem (hint: it won't be). Therefore, a directory and tools using 
random generated filenames. Be that standard `mktemp -p $DIR` or even 
just uuidv4'ing the filename. Either way the concurrency issue would be 
reduced to "an already solved problem".


Secondly, I would want clarity on how this directory is created and 
cleaned up. Personally, I do non-chroot host builds all the time for 
rapid development and I would mind the clutter if every build leaves 
this directory behind - which realistically will end up in the 
`.debian.tar.gz` at some point if not cleaned by the build process 
itself. At the same time, I quite understand always wanting the 
directory for CI/buildd builds.
  An alternative here is that the build tool exports an ENV variable 
for the directory to put these "extra-build-artifacts" into and is then 
responsible for cleaning it up. Since the ENV var would only be exported 
when you wrap your build in sbuild/pbuilder, the clutter would not occur.


However, I think further detailing on this part is between me and 
whoever is going to do it on the pbuilder/sbuild side.



- the buildd operator can configure $artifact_patterns in .sbuildrc if
   they want to (I'm unsure how useful this genuinely is, but maintainers
   running sbuild locally might find it more convenient than editing the
   source package during ad-hoc debugging)
- the patterns reuse machine-readable debian/copyright syntax
- as a result the -artifacts.tar.gz is always a subset of the build tree,
   and inherits its layout, same as Gitlab's artifacts.zip
- if a sufficiently desperate maintainer really wants to, they can tar up
   the entire build tree by specifying a broad enough pattern like '*',
   although this should be discouraged when building 

Re: Produce extra build artifacts during package builds

[Niels Thykier]

Simon McVittie:

On Fri, 02 Aug 2024 at 18:17:52 +0200, Niels Thykier wrote:

Simon McVittie:

In the design that I prototyped, it's declarative, loosely inspired by
the equivalent Gitlab-CI feature:

- the maintainer can write patterns into debian/build-artifacts for
package-specific quirks like GTK's reftests
(#-prefixed comments are allowed)


I am a bit tempted to keep this one out of the spec and leave it to the
build-helper to define it. I find that files in `debian/` are not very
discoverable and they are harder to support properly in tooling like
`debputy lsp server`. Each file format requires extra setup and there is not
a good way to announce they exist unlike fields in `debian/control`.  For
`debputy` based packages, I would prefer to have this in the
`debian/debputy.manifest`, since that will enable me to guide the packager
to its existence and provide on-line documentation for it.


That's fine, debputy could read a list of patterns out of its own input
file and "register" them via whatever mechanism exists
(debian/extra-build-artifacts in my prototype, or writing them into an
"artifacts patterns" directory in your suggestion).

I wanted there to be a straightforward way for a maintainer to opt-in
to this, even if they are not yet living in the debputy future, because
I'd prefer to be able to adopt useful features one at a time, rather
than having to rewrite key packages' build systems in debputy syntax
as a blocker for finding out why their tests fail.  [...]



My argument was that `debhelper` and `debputy` would each define how 
they provide this functionality to their consumers in a way that fits 
how their style. Not that `debputy` was going to be mandatory for this 
feature.




Or, is it possible to have a debputy manifest exist, and get the
information in it about artifacts copied out appropriately, without
needing to make debputy drive the entire build?



The `debputy` framework already has two "integration modes" where `dh` 
drives the build. As an example, the `dh-sequence-zz-debputy-rrr` 
build-dependency is useful for getting rid of implicit `fakeroot` / 
`Rules-Requires-Root: binary-targets` for static ownership while keeping 
*most* things as you know them.


While adding a third mode would be possible at this junction, I would 
not go down this route for the `debhelper` support as it would imply an 
extra dependency for `debhelper` (a circular one at that) plus it would 
not fit the usual `debhelper` pattern.



Mattia's wiki page does list "A reproducible
compiler error (ICE) produces a /tmp/cc*.out containing the preprocessed
source.", which might need some tweaking compared to the "the
-artifacts.tar.gz is always a subset of the build tree".


Hmm, yes, that's unfortunate. This wouldn't be compatible with the
Gitlab-CI feature that I was inspired by, either.

 smcv



Indeed. But as said, I am pretty sure we can figure out a solution to 
this problem. I think it is more of a question whether it will be 
supported initially (might require a per-source TMPDIR too for buildd 
support, so artifacts does not get tainted because the buildd was 
running two builds at the same time, where once had ICE errors and the 
other had not). It will be fun to solve, I am sure. :D


Best regards,
Niels

PS: If anyone is maintaining a `Rules-Requires-Root: binary-targets` 
package and want to migrate away from the implicit `fakeroot` 
build-dependency, please let me know. I am happy to look at providing 
patches (`debputy` is only required for static ownership though. Often 
it is just a matter of masking `chown/chgrp` or `-o` + `-g` for `install`).

Machine readable contributor information (was: Re: Request for feedback on draft: DEP-18: Enable true open collaboration on all Debian packages)

[Niels Thykier]

Fabio Fantoni:

Il 05/08/2024 03:14, Andrey Rakhmatullin ha scritto:

[...]

Thanks for reply, what I mean is precisely a standard field that points 
to a file, inside the package or even an url as already explained can be 
very useful in most cases) that contains all the useful information for 
contributing to that package, including the one you mention. even if 
everyone applied DEP-14 and DEP-18 there would be some differences that 
could be useful to know in a simple and immediate way. and I think this 
is even more useful with the current situation and also very useful in 
case of any future migrations to more standardized systems.


currently you find such information from a simple search and/or looking 
a bit in the source, in the possible git in a few minutes only in part 
of cases, in many other cases instead it requires more time, the 
possible contact of the maintainer, attempts (and then eventually feel 
that it would be better to "improve" your contributions using other 
methods).


a single standard field (to be added optionally) and adding links to 
that file or url in the tracker (if present) I think would bring 
advantages and save time for both contributors and maintainers in many 
cases (when used)




If we go down this route, could we consider making it machine readable 
(in parallel with human readable)[0]. For people doing drive-by 
nmu/patches across many packages, having to manual open link and read 
policies can often take considerable time. It is the small things really 
like:


 * Does this package use `gbp dch` (or some other mechanisms) to
   generate the changelog OR should I include a changelog entry with my
   patch.

 * Does this package use some form of automatic formatting that I should
   apply when I do my changes (if `wrap-and-sort`, then which options)?

 * Does the maintainer prefer MR via salsa or BTS with patches for when
   I want to submit my changes for review. (I get this is the DEP-18
   thread and the answer should be "MR via salsa", but then DEP-18 is
   opt-in, which means it might not be "MR via salsa" after all)

 * Does the maintainer prefer dgit and if so, which of its 5+ different
   documented workflows should I follow?
   (Like how does it manage patches git-wise)

 * Etc.

And yet we do not have good answers for these kind of questions in an 
automated fashion.


I am happy to work on the client side of this problem. I already took a 
stab at something similar (see [1], currently stuck on getting a single 
source of truth data source), so it would fit into the work I am doing 
anyway.


Best regards,
Niels

[0]: I mean a dedicated `JSON` or `YAML` file in parallel to the human 
policy. Shenanigans like parsing special statements from formats aimed 
at humans do not really cut it in my book.


[1]: https://salsa.debian.org/debian/debputy/-/merge_requests/37

Re: Removing more packages from unstable

[Niels Thykier]

Helmut Grohne:

Hi fellow developers,

(modified resend, as first attempt didn't arrive)

please allow me to open a can of worms. Package removal from unstable.
Deciding when it is time to remove a package from unstable is difficult.
There may be users still and it is unclear whether keeping the package
imposes a cost. In this mail I want to argue for more aggressive package
removal and seek consensus on a way forward.



Hi,

I agree with the idea.

On the bias disclaimer side: I was a very vocal proponent for the 
testing auto-removal. I see it as our greatest success of the early 
2010s for reducing mental load of the RT during freezes.


Another bias: For me, implementing a automation on this front is higher 
than getting out the "optimal degree of conservatism" correct. The 
testing auto-remover did not start out with its current criteria either.



What does a package cost?

There are various QA-related teams looking at packages from other
maintainers. When it trips a check, that often incurs time from some QA
person investigating a report or failure. Examples:
  * [...]



You can add to that any "archive-wide" change we have done or will do. 
Other cases where we have or probably did run into such packages also 
include:


 * build-arch (now done)
 * compiler hardening flags (now done)
 * The C++ transition many years ago and the t64 transition (now done)
 * Removing our implicit dependency on `fakeroot`


By virtue of being part of Debian, a package receives attention by a
significant number of developers. Assigning a number is non-trivial, but
we can say for sure that it is significant. Especially developers doing
/usr-move NMUS (e.g. Chris Hofstaedler and Michael Biebl)  now wonder
how much effort to put into the remaining packages.  Removing more
packages would reduce the number of NMUs required there.



As a data point, I am (also?) personally a lot less motivated to 
implement changes or do NMUs when I have to deal with broken FTBFS 
packages in sid. It is one of several roadblocks that make me reconsider 
whether I want to implement a change on a larger level.


It does not make sense for me to change such packages since I cannot (or 
is not motivated to) fix the other problems. But I still need to track 
them in case someone actually fixes the bugs but does not implement the 
change I want to see in it.


> [...]
>

When to remove a package?

I looked at UDD and came up with a suggested query.

https://udd.debian.org/bugs/?release=sid¬bookworm=only¬trixie=only&merged=ign&keypackages=ign&flastmod=ign&flastmodval=366&rc=1&sortby=id&sorto=asc&format=html#results

Human readable explanation:
  * Packages in sid
  * not in bookworm or trixie
  * not a key package
  * affected by an RC bug that has been last modified more than a year ago
  * not among a few selected exceptions



I think this is a good starting point.

On the exception list, I know Josch suggested a popcon limit. 
Personally, I was thinking usertagging RC bugs that are "keep out of 
testing/package is not for stable" bugs and use usertag as filter to 
replace the exceptions.


But either of those or even the hardcoded exception list (including 
tweaks thereof) would be fine for me to get started. All of them gets us 
started and we can refine the exact details over time.



[...]

What do you think about the proposed criteria and suggested set of
source packages? Is it reasonable to remove these packages from
unstable? In a sense, it is extending the idea of the testing auto
remover to unstable. Similarly, a package can be temporarily saved by
mailing the respective bug.



I agree with the proposed criteria as a starting point. Like with the 
testing auto-removal, we should expect some refinements to happen once 
the proposal is implemented.


The code would have to deal with reverse dependencies somehow (which 
both you and Andrey pointed out).


The testing auto-remover has a solution for reverse dependencies that 
could work. It has the advantage (in the eyes of *this* beholder) that 
it is aggressive.
  Though I would be fine with a any version really. This include 
starting with "all reverse dependencies must be eligible for automatic 
removal on their own (or removed manually first)". From there, we can 
always refine the algorithm and its aggressiveness for removal of 
reverse dependencies.



Let us assume that we agree on there being a set of packages to be
removed. What is a reasonable process? Is it ok to just file a pile of
RoQA bugs or is more warning warranted? Should we maybe use a process
similar to salvaging where there is an "ITR" (intent to remove) bug that
is reassigned to ftp after a reasonable timeout?



I would say that at least one warning should be given for consistency 
with the testing auto-remover. I am open to "how" and the timelines.


For me, the most important thing is that the process can be automated 
end to end and that the tool is anchored somewhere to keep it 
maintained. Therefore, I am a

Re: DEP5 and spdx shortname of license

[Niels Thykier]

Jonas Smedegaard:

[...]

DEP5 already encourages (but does not require) use of SPDX shortnames,
except where Debian and SPDX disagree on sensible naming.

See https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/#spdx
and the historical notes at
https://wiki.debian.org/Proposals/CopyrightFormat#Differences_between_DEP5_and_SPDX

Do you have ideas on how to address the documented differences in naming
choices?

  - Jonas



Is it really that valuable for us to have a delta here compared to what 
upstream projects would use?


As I understand it, we are at worst talking `GPL-2.0-only` / 
`GPL-2.0-or-later` (SPDX) vs `GPL-2` / `GPL-2+` (DEP-5). As much as I 
might prefer the DEP-5 variant, I am struggling to see the advantage 
outweigh the cost of divergence.


With my current knowledge, I would strongly be in favor of deprecating 
the unique names for DEP-5 and encourage migration to fully compliant 
SPDX names.


Best regards,
Niels

Re: Automatic ITP closing.

[Niels Thykier]

Charles Plessy wrote:
> Dear David,
> 
> In 2005 you started an effort to close old WNPP bugs that do not get resolved:
> http://lists.debian.org/msgid-search/1127503245.4308.5.ca...@cerdita
> 
> Apparently, this was stopped in 2008. Can you confirm that it is intentional 
> or
> did it just get unnoticed by everybody? The reason I ask is that I am editing 
> a
> documentation that mentions the automatic WNPP closings, and I wonder if I
> should delete this part or not.
> 
> (CC to -devel as it may be of general interest.)
> 
> Have a nice day, 
> 

Hi

I contacted David in relation to this after I took ownership of #264774
(which is about this very problem) and David replied:

> It's available on my home directory on master.

Sadly I forgot all about this bug after I joined the java team. I do not
have access to master, so I have not been able to see this script. David
did not say anything about why the script was not still active when he
replied.

~Niels

PS: I had more luck contacting David using da...@axiombox.com rather
than the debian mail.



signature.asc
Description: OpenPGP digital signature

Bug#551965: ITP: eclipse-rse -- Eclipse Remote System Explorer (RSE)

[Niels Thykier]

Package: wnpp
Severity: wishlist
Owner: Niels Thykier 

* Package name: eclipse-rse
  Version : 3.1
  Upstream Author : DSDP TM Development Team 
* URL : http://www.eclipse.org/dsdp/tm/
* License : Eclipse Public License Version 1.0 ("EPL")
  Programming Lang: Java
  Description : Eclipse Remote System Explorer (RSE)

Remote System Explorer is a framework and toolkit in Eclipse Workbench 
that allows you to connect and work with a variety of remote systems.


Notes:
This is a Dependency for upgrading eclipse-cdt and also eclipse-dltk 
(and possible others)

~Niels



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Team uploads.

[Niels Thykier]

Charles Plessy wrote:
> Dear all,
> 
> It was proposed in 2009 to formalise "Team uploads" in analogy to the "QA
> uploads", as a special case of NMU, where most conventions are relaxed.
> 
> http://lists.debian.org/e13a36b30904052052g73850787vcc8b2035640d7...@mail.gmail.com
> 
> While there was interest, the discussion eventually ended with no action.
> 

I personally like the idea of formalizing team uploads. So far I have
signed packages off by the team - which as a consequence means the
package does not show up on my QA page. As a non-DD, I have to find
sponsors and "lintian clean" packages just "sells better".
  Having read the previous mail exchanges, however, I see the logic in
not using the team and accepting the two lintian warnings.

> In the context of the Debian Med packaging team, I have started to make “Team
> uploads”, for packages that are maintained by my team but for which I do not
> want to add myself in the Uploaders field.
> 
> For these NMUs, I apply the following exceptions:
> 
>  - Normal incementation of version number,
>  - no delay,
>  - no patch to the BTS, but a direct commit to our repository,
>  - start the changelog by a “Team upload.” entry.
> 

In my team (pkg-java) we seem to treat these upload as completely normal
Maintainer Uploads; meaning that the "Team Uploader" is not restricted
to "minimal changes" but may[1] fix whatever needs to be done (e.g. fix
lintian warnings/errors).
  Personally I like this because just doing a NMU-like upload leaves the
package in a mess and unattractive for people to actually take over.

There was a debate about the usage of MU-versioning would make it harder
to track with the package do not have a(n active) long term uploader. I
think this is more of a problem for the team and no QA at first. Because
either the team will pull their ${noun} together every now and then to
fix the package (meaning it is regularly[2] updated) or it will wither
and wane like any other unmaintained package.
  In the former case the package may not be getting as much love as it
ought too get, but the team will keep it "release ready" and in the
latter case it will get NMU repeatedly (from non-team members) like a
"normal" unmaintained package.

It may be a better solution for teams to have a (e.g.) wnpp-like package
to trace which of their packages need a new long term maintainer.
Reporting bugs against wnpp itself sort of suggests that the team is
orphaning it, which is (usually) not the case.

> This triggers Lintian warnings, that I ignore. The attached untested patch
> may solve the problem.
> 
> If others are interested to follow the same approach, I propose to use the 
> following
> wiki page to draft a common reference: http://wiki.debian.org/TeamUpload.
> 
> Have a nice sunday,
> 
> 

Thank you, I am having a nice Sunday; I hope you do as well,
~Niels

[1] Possibly "should"/"must" - I have never tried leaving unrelated
lintian warnings/errors (to the bug(s) I am fixing) in the package.

[2] Being a very relative term here.



signature.asc
Description: OpenPGP digital signature

Re: Team uploads.

[Niels Thykier]

Jan Hauke Rahm wrote:
> Hi Charles,
> 
> On Mon, Mar 08, 2010 at 10:40:47PM +0900, Charles Plessy wrote:
>> Are there other persons interested? Shall I go ahead and submit a patch to
>> Lintian and the Developers Reference (plus perhaps the Policy to include a
>> footnote containing the special changelog lines for NMU, QA, security and 
>> team
>> uploads)?
> 
> Fine for me. I understand there is some use of this proposal in teams
> and I don't see big reasons against it (those being said in the last
> thread about this).
> 
> There is just one thing that bothers me: this new feature would invite
> teams to actually put noone in the uploaders list.  The team would be
> maintainer and no real person would be listed in the package. And I
> don't like this possible outcome. From a QA (and MIA) perspective this
> is not a good idea. So if you're going to write patches as you said,
> please consider adding at least a "should" to policy about setting a
> real person as uploader when the maintainer is a team (i.e.  mailing
> list).
> 
> Hauke

Hi

lintian already warns if a package has no human uploaders and a list as
maintainer (the exception being the QA list) [1], so I believe this has
already been taken care of.

~Niels

[1] http://lintian.debian.org/tags/no-human-maintainers.html



signature.asc
Description: OpenPGP digital signature

Re: About new source formats for packages without patches

[Niels Thykier]

Josselin Mouette wrote:
> Le mercredi 31 mars 2010 à 08:18 +0200, Raphael Hertzog a écrit : 
>>> I agree. dpkg-dev should not be depending on any VCS and it should not
>>> promote any particular VCS either. I know that git is the new black (oh,
>>> wait, that was something else), but I personally don't like it. And I
>>> especially dislike how so many git lovers are trying to push it onto
>>> others, while there are perfectly good reason (not applicable to all
>>> teams or projects of course) not to use git but some other VCS (be it
>>> distributed or not.
>> It was an example. I have never said that dpkg-dev would support only one
>> VCS.
> 
> Supporting several ones would be even worse.
> 
> What’s the point in standardizing over a common and flexible package
> format if it cannot be used with all other tools?
> 

Hi

I do admit I have not completely figured out how it would work and how
it would help us. However, this is exactly why I am not ready to discard
the idea yet.
  That being said, I would (as it is now) actually prefer that it was
just a helper tool that from a VCS could derive a source package of
existing format. That would probably also increase the adoption rate,
since existing tools would work with those formats.

~Niels

I reserve the right to change my opinion on this if the implementation
of the VCS-based source format is awesome enough.



signature.asc
Description: OpenPGP digital signature

Re: About new source formats for packages without patches

[Niels Thykier]

Steve Langasek wrote:
> On Thu, Mar 25, 2010 at 02:03:09PM +0100, Raphael Hertzog wrote:
>>[...]
>> In the general case, switching is a small effort for sure, but in the case
>> pointed out by Neil (he won't convert packages with no patches because he
>> doesn't see the benefit) the effort is almost null, just create the file
>> debian/source/format with "3.0 (quilt)" and you're done.
> 
> Aside from all the packaging tools that aren't quite there yet with 3.0
> support, 3.0 packages break two cheap generic tools that I used to be able
> to use to inspect source packages: zless, and interdiff.  While this loss
> doesn't outweigh the benefits, this is certainly not "win-win", and I would
> appreciate it if you would try to be more understanding of developers'
> natural resistance to this change.
> 

Hi

I recently created a script to diff two 3.0 source packages, which I am
submitting to devscripts (see #575395). It is also able to diff 1.0 vs
3.0 (quilt) by converting the latter to an 1.0 like format and
interdiff'ing them for you.
  If you are interested in it, you can prefetch it from [1]; I certainly
could use some feedback on it.

I will also be looking into providing a way to easily review a single
3.0 package (which would be #575394); suggestions are also welcome for that.

~Niels

[1] Script:
http://www.student.dtu.dk/~s072425/debian/qdebdiff
Doc:
http://www.student.dtu.dk/~s072425/debian/qdebdiff.html



signature.asc
Description: OpenPGP digital signature

Bug#578421: virtual-packages: Retire java-compiler, java2-compiler and java-virtual-machine

[Niels Thykier]

Package: debian-policy
Version: 3.8.4.0
Severity: wishlist
Justification: Policy §3.6
X-Debbugs-CC: debian-devel@lists.debian.org

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi

As of today[1], the Java Policy retired the use of the virtual packages 
mentioned
in the subject line, which brings the Java Policy closer to the actual practices
used by the Java Team.


The replacement guide for the packages are as described below. Please note that
these are guide lines for the average case. If a package does not fit "in",
feel free to contact the Java Team (debian-j...@l.d.o) about it.

[java-virtual-machine]
 - none if already depending(or recommending/...) on a java runtime[2].
 - An alternative list of java runtimes (see [2]) otherwise.

[java{,2}-compiler]
 - default-jdk. If used in an alternative in Build-Depends{,-Indep} then pick
   one of the options (The Java Team recommends default-jdk).

In case you change your Build-Depends{,-Indep} to include default-jdk, you
should update JAVA_HOME to /usr/lib/jvm/default-java if your build system
(e.g. ant) uses it.

Please do *not* switch to default-jdk-builddep without consulting the Java Team
first. On most architectures default-jdk-builddep will pull *two* full Java
Development Environments.
  There is a reason for "insanity"; if you are interested then get in contact 
with
the Java Team.

Thank you in advance,
~Niels

NB: I am subscribed to debian-de...@l.d.o, but not debian-pol...@l.d.o; please 
CC
me accordingly.

[1] http://packages.qa.debian.org/j/java-common/news/20100419T071712Z.html

[2] e.g. one of these default-jre, default-jre-headless, java1-runtime, 
java2-runtime
  If you use indiviual JVMs (e.g. gij or gcj) it may be worth replacing them 
with
default-jre{,-headless} plus alternatives.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)

iEYEARECAAYFAkvMoaIACgkQVCqoiq1YlqyQkwCfSvVWBsnto4SlIeGuitjsOIBd
gZ0AnilwrFjEfUNB2LVf1uoaai5YJlYr
=hAv9
-END PGP SIGNATURE-

Re: proper edit-build-install-test cycle with v3 source packages?

[Niels Thykier]

Timo Juhani Lindfors wrote:
> If I hit a bug in a v1 source package I often do
> 
> apt-get source foo
> cd foo-*
> DEB_BUILD_OPTIONS="noopt debug nostrip" dpkg-buildpackage -rfakeroot -us -uc
> sudo debi ../foo*.changes
> 
> and then run the program inside M-x gdb RET of emacs. If I want to
> test a possible fix I then just use the same emacs to modify files and
> then rerun dpkg-buildpackage and debi to test my changes.
> 
> The above is not really usable with v3 source packages: apparently
> dpkg-buildpackage modifies the timestamps of source files and emacs
> complains that these files have changed on the disk. Should I just
> modify emacs to ignore this warning?
> 
> I asked my question on #debian-devel and was given the suggestion that
> I should copy the source tree to a different directory for build. This
> works but is slow and also has the problem that M-x gdb will open
> files of the build directory instead of the original one. If I then
> accidentally modify something in the build directory it will get
> overwritten by the build.
> 
> 

Have you tried adding "-b" to dpkg-buildpackage as well? I think that
should do it (unless the build/clean does weird things).

~Niels




signature.asc
Description: OpenPGP digital signature

Re: bindv6only again

[Niels Thykier]

Marco d'Itri wrote:
> On May 05, Vincent Danjean  wrote:
> 
>> the bugs in applications. I would find very strange if we release sqeeze
>> with a broken sun's java (even if it is non-free) and no good replacement.
> Me too, but I still hope that it could be fixed.
> Maybe the maintainer could provide some of his toughts...
> 

I do not think the maintainers can do anything about sun-java6 other
than ask users to modify the netbase config file. To the best of my
knowledge there is no source code available for sun-java6.

On a related note Vicent; if the person testing the issue has not
already done it, could you convince him/her to file a bug against the
plugin?

~Niels




signature.asc
Description: OpenPGP digital signature

Bug#581422: ITP: eclipse-mylyn -- Task support for Eclipse

[Niels Thykier]

Package: wnpp
Severity: wishlist
Owner: Niels Thykier 
Owner: Niels Thykier 

* Package name: eclipse-mylyn
  Version : 3.2.1
* URL : http://www.eclipse.org/mylyn
* License : EPL v1.0
  Programming Lang: Java
  Description : Task support for Eclipse

 Mylyn integrates task support into Eclipse. It supports offline editing
 for certain task repositories and monitors work activity to hide
 information that is not relevant to the current task. Also included is
 the Mylyn Focused UI for reducing information overload when working with
 tasks and the Bugzilla task connector.


~Niels



-- 
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/20100512211025.9818.54344.report...@getsu.thykier.net

Re: .deb package for a library generation

[Niels Thykier]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 2010-08-08 15:45, Zvi Dubitzky wrote:
> I need to generate a Debian package for a library 
> As an exercise I tried it with   libvirt . 
> I am running a Ubuntu 8.10 . and use the libvirt.0.6.1 tar.gz 
> 

Hi,

Thanks for your interest in Debian, unfortunately I do not have a lot of
time so this message will be rather brief.

I have added the mail to debian-ment...@l.d.o which is our dedicated
mailing lists for how to do packaging and put you in CC, since I was
unsure whether you would receive the email otherwise.

> 
> For the library package I followed the Ubuntu instructions at  : 
> https://wiki.ubuntu.com/PackagingGuide/Basic
> (I first generated  a .deb for the hello program and it  went ok)
> For the library I did :
> 1.  got the tar of libvirt .  made a copy to orig.tar.gz
> 2. untarred the tared library . cd to the untarred code
> 3.  there ran :  dh_make -e your.maintai...@address . This created the 
> debian directory. Got no bad 
>  commnetsfrom lintian.
> 
> 4. ran : debuild -S -us -uc  (to avoid gpg for now)
> That generated the ../*.dsc and ../*.diff.gz  . Looks ok.
> 
> 5. ran: sudo pbuilder build ../*.dsc  ( changed the debian/rules to have 
> ./configure --with-xen=no otherwise
>it complained about xs_read missing in libxenstore - which exists . 
> libxen3, libxen3-deb are installed ok)
> 
>   But now during the ./confugre run I get the following message :
> 
> .
> checking for pkg-config... no
> checking libxml2 xml2-config >= 2.5.0 ... configure: error: Could not find 
> libxml2 anywhere (see config.log for details).
> make: *** [config.status] Error 1
> dpkg-buildpackage: failure: debian/rules build gave error exit status 2
> pbuilder: Failed autobuilding of package
>  -> Aborting with an error
>  -> unmounting dev/pts filesystem
>  -> unmounting proc filesystem
>  -> cleaning the build env
> ...
> 
> pkg-config is installed and the newest . libxml2 is installed  and newest 
> (/usr/lib/) and  xml2-config --version gives  2.6.32
> 
> so why does the system complain : Could not find libxml2 anywhere  . BTW: 
> config.log was not generated yet .
> 
> Any idea/ help ?
> 
> thanks
> 
> Zvi Dubitzky 
> Email:d...@il.ibm.com
> IBM Haifa Research LaboratoryPhone: +972-4-8296182
> Haifa, 31905, ISRAEL 
> 
> 
> 


dh_make cannot deduce every Build-Dependency of your package, which is
likely to be your problem. As I recall (but I have not used it in a
while) it only generate a set of template files to get you started.
  Also pbuilder builds your package in a "clean chroot" where it only
installs the packages listed in Build-Depends and Build-Depends-Indep of
your debian/control (+ the "build-essential" packages).

So you probably have to open the debian/control file and add the correct
build dependencies there.

I apologize for the short answer with no reference to relevant
information, but I am really out of time :)
  I am about to leave DebConf10 (like a lot of other Debian people).

~Niels

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

iEYEAREIAAYFAkxewlcACgkQVCqoiq1YlqykKACfTId9Pw0Q2yerPPeuUXnyZbFU
QIAAoMV8gYAjuecmaHjkN8bdvPdwENWX
=GAMJ
-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/4c5ec258.8080...@thykier.net

Re: debuild + xvfb-run + Eclipse

[Niels Thykier]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 2010-09-27 20:40, Josh Kelley wrote:
> I'm trying turn an Eclipse CDT (C/C++ Developer Tools) managed build project
> into a Debian package and am having a lot of trouble.  Since it's a managed
> build project, I can't simply run make.  Eclipse can start a build from the
> command line (as described at
> http://stackoverflow.com/questions/344797/962610#962610), but it apparently
> still requires an X server.  I tried using xvfb-run to accommodate, and I
> simply can't get it to work.  xvfb-run works if I invoke it directly, but
> whenever it's invoked from debuild, Eclipse locks up.  I've tried a few
> different approaches to fixing it:  I tried using -e for xvfb-run to see
> errors, but nothing looked relevant; I tried running xvfb-run from fakeroot,
> to see if fakeroot was the source of the problems, but it worked; I checked
> my environment variables, to see if debuild was stripping something that
> Eclipse + xvfb-run needed, but nothing looked relevant.
> 
> Any suggestions?  Any known issues or gotchas in running xvfb-run from
> debuild?  What's different about debuild spawning xvfb-run versus spawning
> it myself?
> 

Hi

Perhaps you could convince your upstream of using a non-eclipse build
system with eclipse plugin support (e.g. autotools using the integration
plugin provided by the LinuxTools project[1]).

~Niels

[1] http://www.eclipse.org/linuxtools/projectPages/autotools/

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

iEYEAREIAAYFAkyhBnsACgkQVCqoiq1YlqxVuwCgydUKvoplg1D6ZSpeECXCuZat
7MwAnj/0fD+xeHueIMQGUnRla+QfkJw7
=+xhO
-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/4ca1067c.7040...@thykier.net

Bug#600171: ITP: eclipse-jgit -- pure Java implementation of the GIT VCS

[Niels Thykier]

Package: wnpp
Severity: wishlist
Owner: Niels Thykier 

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

* Package name: eclipse-jgit
  Version : 0.9.3
  Upstream Author : Eclipse Development Team
* URL : http://eclipse.org/jgit/
* License : BSD-like
  Programming Lang: Java
  Description : pure Java implementation of the GIT VCS

Needed for eclipse-egit.


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

iQIcBAEBCAAGBQJMtsOWAAoJEAVLu599gGRC+MIQAIHoFQWKCR3ZnpOMJneoe4oR
VZAXfF50FZiyODJq1UHK0GUzc3JeCWIlwowMoatCHh9ENRPSbyOj0f3Dc60jJalu
WikUVyYTQTjC7vGtoI1WZ1X5z5JwjCnfkrC8TpxcySA3dXdx+h08BhEZf4azpbv9
jMbY6UXLlbnqr9tooFwcOkKj8Pk+aMwMk7jvAytLrADqxAWDaw6/rVeIWbnEHzkv
wOozh/f1Zn1yqVh8Gls9VylDe+VTUNXhoGBh3Pw8w2ybKCBeJBd6gt8atwR74NLH
LMf6AzGhe61/zgl7bPW5jHXk8Bik8iQ56o8tcVhEvPBQKAXq2iuMjVU8dMQHTvMx
ZIGWdasMaDZKHq1C1gkLXckJ4PJ00yhMzP53sytiEi/tQiGGS7HFcRzOZXzdyn2c
ze94JijOfHdN3dXtGYaV/Xrh/aX5B1xSLy9KOXsySaFgrpwPzoTivZVQ6JVAXboc
b5J+m9MBN8X4KA3XTyDEUQgWvRfOwVBxgI2E53beXdkPKQ/26+cbuBGOanAQ7GN0
+w5zx5bd1t78SXx+rXwJDiJe81ySaQ8HAf1Ez1NAM4Hfx1c1G9HZTV1kju1WwpDg
G345w90j36y/yxJUfiTtdUvEmHV4A+C9wc9CaVtXCS0/MveQP1dtECysGrYKr/p1
cAbgecbZ6UtlYYo5J17l
=c0ys
-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/20101014084724.18397.94034.report...@getsu.thykier.net

Re: binNMU for Arch: all packages.

[Niels Thykier]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 2011-01-14 22:22, Yves-Alexis Perez wrote:
> On ven., 2011-01-14 at 18:05 -0200, Marco Silva wrote:
>> This documentation is generated automatically
>> from the source code, using a documentation generator called haddock.  
>> Haddock
>> is part of the compiler and is also updated when the ghc is.  It would be
>> good to regenerate the documentation for each library too, when a new ghc
>> arrives. 
> 
> I don't really know anything about haskell, but is it really needed to
> regenerate library docs each time the compiler is updated? What does it
> give?

Hey,

It is possible the Java packages could use binNMU for arch: all packages
as well.  There was some talk about injecting "ABI" versioning in Java
Libraries at DebConf10, so we could handle ABI breakage in a similar way
to how it is done with regular libraries.

~Niels

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

iQIcBAEBCAAGBQJNMZp0AAoJEAVLu599gGRCG9AQAIkbZm70clVfWLOhqy12zZgC
EEytgjw9d8twNbY5kib+xWxGzOT7I/4LrC0ayoF5+VacYmgAhlBydoarHK1oJvyw
ExAxfYiADLKwoxsoFHZNlbBCEkoLYnx8sdmg/Yu6CVVeNtp+xwKCfk9QLGBSieJw
nzTDsd5+GTJrgH6FGW3RVwC7XQqhuGKVD34BxHnO3SqQiFjbiMgSxkU9qa3Vb5rp
G8qSm4oRm94B8k4DU920WgcjdISAY/ZnlILwYwsOjx5DFr5fEQjXTsIHEc9dad4S
+WZPOS2YkXdXbHOrS5c9rGJICHtjdcThRofr6onllOoBM8zbeU3B3Fexwf6Unm9v
0N/KpoTN787yfE78HJBOdOBTXQFGqtX4qvRvl2ZpXmULga5kZgjvu9Rrgf2+d5Ki
/31Fc8eSzNsFRV5/FDLXdQ55ak98m+Fh5s0tVtD0oCs9hXxWWE8tl1FN/Z42/+y1
XNyuzkGhTPYRPCAubeCOGWX1yvIAwVino+CEQpWDeRzeJCTixng5V+JH+iwOZWIQ
VIwEIyj4TkbkK0fLycjzXMuelXmvAteZ6ANcOtGMYRTD99hCInKXPfu98vfu/4u0
ec01EIDphzcbpBoDwU9Qz4K/r7SDrThZpsHvesZnCYSYgs4/UuSv0rsHhfNKnRob
saOk9gZyM0BaVUhiBDTQ
=/CL/
-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/4d319a75.3080...@thykier.net

Bug#612358: ITP: lpg-generator-java -- Java Runtime support for the LPG parser

[Niels Thykier]

Package: wnpp
Severity: wishlist
Owner: Niels Thykier 

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

* Package name: lpg-generator-java
  Version : 2.0.20
  Upstream Author : Philippe Charles 
* URL : http://lpg.sourceforge.net/
* License : EPL-1.0
  Programming Lang: Java
  Description : Java Runtime support for the LPG parser

The LALR parser generator (LPG) is a tool for developing scanners and parsers
written in Java, C++ or C. Input is specified by BNF rules. LPG supports
backtracking (to resolve ambiguity), automatic AST generation and grammar
inheritance.


Rationale for packaging this: eclipse-cdt appears to have modules depending on
this, which are currently disabled.
  If it turns out that I also need the lpg-generator (written in C/C++), I will
probably put both parts into the same source package.

Note: On the upstream author I chose Philippe, because SF lists Philippe as
project manager and there did not appear to be a team mailing list.

~Niels


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

iQIcBAEBCAAGBQJNUIemAAoJEAVLu599gGRCa50P/RG7i9uw5TG809g2Y339BLus
PbwTE0dPXwvo1DwmXLcyc20pRIxlMqMvnjGZQ/C2s80A+SInmJ/52yE4zqko3pjL
CCphJe/MUQR+MlkfEmh0X9bk6XaBYmx5oRq3FK4kw10BICKD/vrmRLuZGoHi1Wyk
wRh24FGeuQoxhBYmyuMspClVG8Mn1tcZX6knyI3HrCZ53kFZm/c2oPBvAIx3jK9O
VLJHMrfjjYc3FzX6HFE92xgwivs0UdtNTkfkwzpO2VvhXCTWTaoj7ky7yUsGF9TF
nkBmTkHaIAosGZXY/dFCEqM3Svt5Yn6xZuGwYtC1MFqhvk8Kj904/YEcFKymueu2
XjronY6vNYUVjTNuAELNA44aygbjg40NUpjExvcKvBro1M+t7oEmgLVU5p+YLrL5
exqfcOGAqXk9QldiLQs6EnXLUF1ZffxfMR1Dua7x/jdT8Q9vL0TQUvAAFJhYx1Bk
JNhFfEAuS6uiLNvNjCSRVumgV24Bm97FUE9QkYpy8f9OAGsFSXoVNtMUuVillnl3
HIsNd84aGtbsJBGQeH6yhuVxOMTDfljC49AvOOlB7VmmCFODGtwTLyMOTI3Q0cm5
lhPDZeaAolETtHlnQl3aLttvZhuf30ZLjxAx9lpKIh6CPMiHG83qKEjeKm4i0q66
Hw39Yw2qdST9SSALyJNi
=QM5H
-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/2011020842.15341.46842.report...@getsu.thykier.net

Re: Best practice for cleaning autotools-generated files?

[Niels Thykier]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 2011-03-15 23:55, Neil Williams wrote:
> Using autotools with Debian native packages can be a real PITA and
> source format 3.0 just gets it wrong mostly. Most other tools also get
> it wrong, even svn-buildpackage. If I knew how to fix it reliably -
> *without* putting huge amounts of stuff into the VCS or massively
> extending the build by not using make dist (and missing errors by not
> using make distcheck), I'd stop using my own hand-crafted scripts to
> release these projects. Makes me wish I could pretend that these really
> are upstream packages.
> 

While I have not used it myself, it seems dpkg-source can (partly) help
you here by using the "extend-diff-ignore" option in
debian/source/options.[1]

~Niels

[1]
http://raphaelhertzog.com/2011/01/28/3-ways-to-not-clutter-your-debian-source-package-with-autogenerated-files/

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

iQIcBAEBCAAGBQJNgHG3AAoJEAVLu599gGRCAuMQAKthJyLrpW9PUQNc11G5x/tw
emhRttTwaT7Xz9gmpQg6Wp5rFmFCSDjJjZ8bAa/e5G8YyeoXXjsGsK6fN0bjdu8O
8TaRBFlMpimnmfKH2ONfwqSS2chib8CK55vKGJ6ol0TDNqj9TT/xJCPVTKWbkbem
IYACZPha5i0yqlbd0DdN/OrpJtyHlIhVTmHDFdS93sjc/yA2oxJ4dSiZ8J/Exqki
arKJe7K3g1xrInb8U/Z8i8eL7zGiPsq8KFsZEkByGipXGEYsCMz6yi8JS/048S8c
pNy9Jkw6o/bC98FhFfLsgdy8T1gtqKKoVs5ad+9Vl7YI5ssjzJRP0BEsR/EKDfxP
11q8EjIIsxw4L/+IXmUPsGO5UBnAwWkKWJYuVCqga2IjM6NK5Hpqr4u9laJi805f
RjPIjo541kDm3TmShXLFfJJNVSBp+lPr+3u0Yo229P08UpgDf84wfXE3I27IJS3j
M0wivqz5rGkfMLK+lyv9Fso5GQmVydrqhxVAHo/9nQCZi0Xz5u3iGjXhNBrORr9M
CfK18MQsWe83XPtftsWcMtGiU4gMg0kfAzkzT7Y4UAtQKU6FKIQSX7i4oT/DSJuN
IaIoo6HB7d6r0Ay+QlASiuneXtU2zHwL2iWFr7GZhmTQbfoE7lMXAnDWNjiJ9CvN
kQrkHxAwFt65wvRZ60E0
=Rd7x
-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/4d8071b8.6000...@thykier.net

Re: libjpeg-turbo transition

[Niels Thykier]

On 2014-07-09 18:51, Mike Gabriel wrote:
> Hi all,
> 
> short notice from my side... (defacto / so far libjpeg-turbo package
> maintainer)...
> 
> I can start working on the libjpeg-turbo transition at the beginning of
> August. First step is, I guess, providing libjpeg-turbo with libjpeg
> compat mode enabled.
> 
> [...]
> 
> If people think that starting with the transition in August is too late
> for Jessie, I will be happy about people joining in and starting any
> part of the required work earlier. Thanks!
> 
> light+love,
> Mike

Hi Mike,

Thank you for your efforts.

If you plan on doing this transition for Jessie, please do keep the "5th
of September" deadline in mind[1].  Please also consider filing a
transition bug to help us (the release team) get an overview of the
affected packages at your earliest convenience.

Thank you in advance,
~Niels

[1] https://lists.debian.org/debian-devel-announce/2014/07/msg2.html

See the section named "Freeze reminder ".



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/53bd7f87.3050...@thykier.net

Re: New dash in experimental

[Niels Thykier]

On 2014-10-01 16:04, Gerrit Pape wrote:
> Hi, I uploaded a new version of dash (0.5.8-1) to experimental, please
> help testing it.  If no critical issues arise, I plan to put this
> version into unstable in about two weeks.
> 
> Regards, Gerrit.
> 
> 

Hi,

Have you tried rebuilding the archive with the new version of dash?  If
not, perhaps get in touch with David Suárez and ask if it is possible.

My concern is that we are getting really close to the freeze - the
proposed upload date for dash is 3 weeks before the freeze.  Having a
package from build-essential blowing up that close to the freeze is that
last thing we (i.e. the release team) wants at that point.

~Niels

PS: To clarify to all: The freeze will occur in testing, but (unblocked)
updates will come from sid.  So if sid is broken, it can adversely your
ability to get fixes into testing.  See the freeze policy for when
changes /must/ go throw unstable.

[freeze policy] https://release.debian.org/jessie/freeze_policy.html


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/542c34e1.7040...@thykier.net

Bug#765076: general: No way to have a clean chroot for building packages

[Niels Thykier]

On 2014-10-13 13:12, Santiago Vila wrote:
> Package: general
> 
> Before systemd arrived, it was possible to have a chroot free from
> init packages (not needed to build packages).
> 
> [...]
> 
> In either case, the end result is that I'm forced to install init
> packages in a chroot which is used to build packages, something that
> didn't happen in wheezy. This is clearly a regression and I hope that
> it is fixed before the release of jessie.
> 
> Please reassign/clone as appropriate.
> 
> Thanks.
> 
> 


In Wheezy, sysvinit was essential, so you would have the same issue in
stable (just with a different init system).

~Niels


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/543bbae1.6030...@thykier.net

Re: Packages using old dpkg tools paths

[Niels Thykier]

On 2014-11-03 11:23, Guillem Jover wrote:
> Hi!
> 
> [...]
> I'm planning on starting to file bug reports for the source packages
> below (BCCed). I've not checked (yet) how severe the dpkg-statoverride
> ones are, but if most of them do not get fixed, I might consider
> reintroducing the compat symlink for that one alone if the release-team
> (CCed) sees fit to that. :/
> 
> [...]
> 
> Thanks,
> Guillem
> 
> 

Hi Guillem,

Could you please re-instate all the compat symlinks for Jessie?  Besides
the package listed, we are also concerned about the upgrade path from
Wheezy.

~Niels





signature.asc
Description: OpenPGP digital signature

Re: Jessie Freeze -> What is the next release name? (jessie+1)

[Niels Thykier]

On 2014-11-08 18:06, Osamu Aoki wrote:
> Hi,
> 
> On Wed, Nov 05, 2014 at 11:56:49PM +, Jonathan Wiltshire wrote:
>> The release team is pleased to announce that Debian 8.0 "Jessie" is frozen.
>> Further updates to this release will be restricted to bug fixes only.
> ...
> 
> I thought usually this type of announcement comes with next release
> name.
> 
> I was going to update web site (later) and debian-reference package (in
> November) in proper timing.  Did I miss some announcement? 
> (Too many init discussion posts )
> 
> Regards,
> 
> Osamu
> 
> 

The release name of Jessie+1 will be announced tomorrow morning
(09:15-10:15 UTC) at the Release update at the Cambridge mini-DebConf.

~Niels






signature.asc
Description: OpenPGP digital signature

Re: debootstrap loading both libept1 AND libept1.4.12, .. and fails!

[Niels Thykier]

On 2012-04-18 08:06, Mike Gabriel wrote:
> Package: libept1.4.12
> Version: 1.0.6.1
> Severity: Important
> 
> Hi Oliver, hi Enrico, hi all,
> 

Hi,

I am closing this bug #669203 as not a bug, because ...

> On Di 17 Apr 2012 17:29:53 CEST olivier sallou wrote:
> 
> [...]
> 
> libept1 depends on libapt-pkg4.10. However, libapt-pkg4.10 is not
> available in SID anymore, so libept1 fails to install during debootstrap.
> 
> 
> dpkg: dependency problems prevent configuration of libept1:
>  libept1 depends on libapt-pkg4.10; however:
>   Package libapt-pkg4.10 is not installed.
> dpkg: error processing libept1 (--configure):
>  dependency problems - leaving unconfigured
> Errors were encountered while processing:
>  libept1
> 
>

Looking at the PTS[0]:

"""
This package is part of the ongoing testing transition known as apt.
"""

So this /temporary/ uninstallability is expected, while libept is
rebuilt against the new version of apt.  Please see [1] for a list of
affected packages.

[0] http://packages.qa.debian.org/libe/libept.html

[1] http://release.debian.org/transitions/html/apt.html

> [...]
> 
> Any idea how to fix this / work around this???
> 
> Thanks,
> Mike
> 

For transitions, wait till the relevant packages have been rebuilt.  In
other cases, the package may be broken or an uncoordinated transition
may have started.  In the latter case, please contact the release team.

~Niels



-- 
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/4f8e5d5c.8010...@thykier.net

Candidates for removal from testing

[Niels Thykier]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi,

We are considering removing the following packages from testing as they
have unfixed RC bugs filed against them. The packages can be found in
the attached dd-list.  The bugs that put them on this list can be found
in the removals.txt file (also attached) just above the package name.

The packages have been selected based on the following criteria:
- - The package had at least one RC bug without activity for the past
  14 days.
- - If a bug is assigned to multiple packages, both packages will be
  affected.
- - The RC bug affects both unstable and testing.
- - The affected package does not have any reverse dependencies in
  testing.

These tools[1] are rather new and therefore we have randomly chosen
about 30 packages from the originally generated list. These packages
were manually verified to fit the criteria listed above.

If the relevant RC bugs in the affected packages are not dealt with
before the 27th of May., the packages will be removed from testing. Note
that "dealt with" may also include downgrading a severity-inflated bug
or fixing affected versions in the BTS.

Note, this email has been BCC'ed to the respective
*@packages.qa.debian.org emails.

Thanks,
Niels (on behalf of the Release Team)

[1] The tools are available from:

svn://svn.debian.org/svn/collab-qa/rc-buggy-leaf-packages




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

iQIcBAEBCAAGBQJPr7gAAAoJEAVLu599gGRCmikQAJFzi/Nr4fIwu+sb4565EJqt
jdftqk1TRPzm4D3xEESFrTdFT0Q6c+AV9aeMHWFwdSH/9A7DQ1AN2BcEyxMFsImj
CMGFnJpybIIu8MtinK+Sakd0OsPx16L4me4pnMQI/hFw5bRa+qm1ZqjFJTnI3ZtD
VgYh7YSkoUPJ53qVHwZXDXCA4HDX1ogSChJlJMnvZeH/A1aC2eH92nYvYuYeGYiY
m56kp8gFVrN7u25bB++kZdK///so35f2zeFDio0Ar1/OKVBcNxY9984ZXS+oJ7oj
bvb/ItAymFpeybhCpmpjs2E8nf/qjJ4S6O0gszokMIBynT3Q0i12DU/wBVduxJ80
InkdiAFH8UPJnNMpOHR23KFkUSNxBMMViH4n+654MPvS6GCX0mQUWGHqcairHT5A
+O2l8PETB1BQwGfcB2VvVge2s80IhzRlNAhvxwhkiLtQyf9uMAXtc3RJ3Sq92Wnl
WM/Dv8HY59iayLnyMn267GK7yIeLFvUBLB/AAaXIdBdLMzv/gnVhfxieqzS5OIaY
N9Vfta0cHumTI+Gv/6cNHCb2H/5vH/zYlnja+Cv6o/k91VAyQYAvEuWS37LniGtl
hjvCMMlnXEaRbD1eUznOS/QG7s9fDYKZZcpKkCQtWUCwsP+F6kY+A1WJ25oWtCLU
FQ1BHddfyYN4i/oi0Uh1
=MR2I
-END PGP SIGNATURE-
Adam Schmalhofer 
   pytest-xdist

Andrea Colangelo 
   tennix

Antonino Arcudi 
   audacious-analog-vumeter-plugin

Benjamin Mako Hill 
   python-simplemediawiki

Bert Agaz 
   tahoe-lafs

Christian T. Steigies 
   bumprace

Clint Adams 
   haskell-hledger-interest (U)

Daniel Watkins 
   python-django-filebrowser

David Moreno Garza 
   htp (U)

Debian Games Team 
   rocksndiamonds (U)
   visualboyadvance

Debian Hamradio Maintainers 
   ax25mail-utils

Debian Haskell Group 
   haskell-hledger-interest

Debian JED Group 
   slang-slirp

Debian KDE Extras Team 
   icecc

Debian Multimedia Maintainers 

   morituri

Debian Python Modules Team 
   python-django-filebrowser (U)

Debian Xiph.org Maintainers 
   oggvideotools

Diego Escalante Urrelo 
   htp

Dmitry E. Oboukhov 
   rocksndiamonds

Evgeni Golov 
   visualboyadvance (U)

Fabian Fagerholm 
   albatross

Fathi Boudra 
   icecc (U)

Ghe Rivero 
   keystone (U)

Hamish Moffatt 
   ax25mail-utils (U)

Iulian Udrea 
   pidgin-facebookchat (U)

Jaime Robles 
   ax25mail-utils (U)

John Francesco Ferlito 
   oggvideotools (U)

John Goerzen 
   hpodder

Jonas Smedegaard 
   morituri (U)

Jonathan Davies 
   pidgin-facebookchat

jppy development team 
   jppy

Julien BLACHE 
   eikazo

Julien Danjou 
   keystone (U)

Jörg Sommer 
   slang-slirp (U)

Kevin M. Rosenberg 
   cl-memstore

Mark Purcell 
   icecc (U)

martin f. krafft 
   jppy (U)

Masayuki Hatta (mhatta) 
   latex209 (U)

Micah Anderson 
   tahoe-lafs (U)

Michael Piefel 
   kimwitu++

Monty Taylor 
   plywood

Nicholas C Piper 
   jppy (U)

Nick Ellery 
   visualboyadvance (U)

Nicolas Roudaire 
   piwigo

Norbert Preining 
   jppy (U)

Ola Lundqvist 
   visualboyadvance (U)

Patrick Ouellette 
   ax25mail-utils (U)

PKG OpenStack 
   keystone

Rudy Godoy Guillén 
   htp (U)

Thomas Goirand 
   keystone (U)

TSUCHIYA Masatoshi 
   latex209

# 651655 623637
slang-slirp
# 656089
icecc
# 652958
oggvideotools
# 616108
pidgin-facebookchat
# 666598
albatross
# 666307
htp
# 613344
bumprace
# 668104
pytest-xdist
# 663943
visualboyadvance
# 41
kimwitu++
# 662044
audacious-analog-vumeter-plugin
# 664907
tennix
# 653312
tahoe-lafs
# 669386
plywood
# 661667
keystone
# 663186
cl-memstore
# 653319
eikazo
#661922
morituri
#655815
jppy
#645164
python-simplemediawiki
#664936
ax25mail-utils
#664953
hpodder
#650215 #662130
piwigo
#651620
rocksndiamonds
#634020
python-django-filebrowser
#666364
haskell-hledger-interest
#669382
latex209


dd-list.sig
Description: PGP signature


removals.txt.sig
Description: PGP signature

Re: udeb and data.tar.xz files?

[Niels Thykier]

On 2012-05-14 21:16, Theodore Ts'o wrote:
> I'm very confused about what the status is regarding udeb and
> data.tar.xz.  Are they allowed or not?  It seems at the moment that
> dh_builddeb is creating them by default, and lintian is complaining that
> this is an error.
> 
> I've done a search through the web and debian-devel and it looks like
> things are in transition.  That is, there are people hoping that the
> udeb infrastruction will support xz compression, and even an assertion
> that the lintian complaint is not obsolete and those references *appear*
> newer than references to the udeb-uses-non-gzip-data-tarball error.
> 
> Or I could be conservative and hard code something explicit in
> debian/rules to force dh_builddeb to pass -Zgzip to dpkg-deb, but that
> will be ugly, and risks being obsolete at some point.
> 
> Can someone tell me what's up, and ideally update the text at:
> 
>   http://lintian.debian.org/tags/udeb-uses-non-gzip-data-tarball.html
> 
> ... so developers can know what to do?
> 
> Many thanks,
> 
>   - Ted
> 
> 

Hi,

Lintian is outdated (#664600) and the fix has been commited to the git
repository[1]

~Niels


[1]

http://anonscm.debian.org/gitweb/?p=lintian/lintian.git;a=commitdiff;h=ec4e5cbf5ceea35db5948be21d3b03d696607b0f


-- 
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/4fb1624f.3060...@thykier.net

Re: udeb and data.tar.xz files?

[Niels Thykier]

On 2012-05-14 22:01, Ted Ts'o wrote:
> On Mon, May 14, 2012 at 09:51:43PM +0200, Niels Thykier wrote:
>>
>> Lintian is outdated (#664600) and the fix has been commited to the git
>> repository[1]
> 
> I saw a bug report requesting that packages that failed the lintian
> udeb-uses-non-gzip-data-tarball check should be summarily rejected.
> Did this actually get implemeted on the ftp server?  i.e., do I need
> to wait until the new version of lintian gets propgated out to the
> debian servers, or if I'm in a hurry, hack dh_builddeb to generate a
> udeb that doesn't use data.tar.xz?
> 
> I just want to know what my options are.
> 
> Thanks,
> 
>   - Ted
> 
> 

Hi,

To be honest, I was my understanding the auto-reject had been
temporarily disabled.  However, according to [1] it appears to still be
active.

If you are in a hurry, dh_builddeb should work.  Otherwise, I believe
the ftp-masters can manually accept a package that would have been rejected.

~Niels

[1] http://ftp-master.debian.org/static/lintian.tags


-- 
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/4fb1673f.3020...@thykier.net

Re: tech-ctte help needed: main dependencies on non-free/contrib

[Niels Thykier]

On 2012-07-17 19:35, Russ Allbery wrote:
> Hello all,
> 
> [...]
> 
> It would also be quite interesting, although much harder to determine,
> whether there are any scenarios where such a dependency would result in a
> non-free package being installed by default.  If, for example, there's a
> dependency on foo | foo-nonfree and some packages conflict with foo but
> not with foo-nonfree such that a dependency resolver may pull in
> foo-nonfree in preference.
> 
> Thanks!
> 


Hi,

I suspect installability checking of all packages should find them if
they are there.  One run with non-free+contrib and one without - the
"newly" uninstallable between the two runs should be set you are looking
for.  It does not catch issues like "foo-nonfree | foo", but they would
be caught by your other query.

~Niels


-- 
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/5005a8eb.6020...@thykier.net

Re: Some doubts about patching

[Niels Thykier]

On 2012-07-28 11:41, Jose Antonio wrote:
> Hi all,
> 
> I've been checking the website of "Release-critical bugs status" at
> http://bugs.debian.org/release-critical/debian/all.html. And I have several
> questions:
> 
> * I have installed Wheezy but not Sid nor Squeeze: Can I filter the bugs to
> find only those corresponding to Wheezy?
> 
> [...]

Hi,

http://bugs.debian.org/release-critical/ has a "Only bugs relevant to
testing" link, which may be what you are looking for.


~Niels


-- 
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/5013b67b.90...@thykier.net

Re: packages with E: md5sum-mismatch in the archive

[Niels Thykier]

On 2012-09-20 18:52, Andreas Beckmann wrote:
> On 2012-09-18 09:30, Andreas Beckmann wrote:
>> Just to give a short impression what we can find here:
> 
>> guile-1.6-dev_1.6.8-10.1
>>   /usr/lib/libguile-ltdl.la
>>   /usr/lib/libguile.la
>>   /usr/lib/libguile-srfi-srfi-13-14-v-1.la
>>   /usr/lib/libguile-srfi-srfi-4-v-1.la
>>   /usr/lib/libguilereadline-v-12.la
> 
> [...]
> 
> Can someone do a lintian check for just this tag on the whole archive, 
> all architectures, all releases? That's just *.deb on a full mirror :-)
> And ports should be checked, too.
> 
> Andreas
> 
> [...]
> 
> 

I am doing a lintian run for amd64 + i386 on stable for starters
(limited to md5sum-mismatch).  I think that (plus the normal sid runs)
should cover most issues.

~Niels


-- 
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/505b689f.8030...@thykier.net

Re: packages with E: md5sum-mismatch in the archive

[Niels Thykier]

On 2012-09-20 21:03, Niels Thykier wrote:
> On 2012-09-20 18:52, Andreas Beckmann wrote:
>> On 2012-09-18 09:30, Andreas Beckmann wrote:
>>> Just to give a short impression what we can find here:
>>
>>> guile-1.6-dev_1.6.8-10.1
>>>   /usr/lib/libguile-ltdl.la
>>>   /usr/lib/libguile.la
>>>   /usr/lib/libguile-srfi-srfi-13-14-v-1.la
>>>   /usr/lib/libguile-srfi-srfi-4-v-1.la
>>>   /usr/lib/libguilereadline-v-12.la
>>
>> [...]
>>
>> Can someone do a lintian check for just this tag on the whole archive, 
>> all architectures, all releases? That's just *.deb on a full mirror :-)
>> And ports should be checked, too.
>>
>> Andreas
>>
>> [...]
>>
>>
> 
> I am doing a lintian run for amd64 + i386 on stable for starters
> (limited to md5sum-mismatch).  I think that (plus the normal sid runs)
> should cover most issues.
> 
> ~Niels
> 
> 

Full of stable amd64 + i386 is done.  Only cm-super appears in the log
and it overrides all the tags.  By the looks of it, it is the same as in
sid, so ...

~Niels



-- 
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/505f4b5b.7080...@thykier.net

Candidates for removal from testing (2013-06-04)

[Niels Thykier]

Hi,

Our automated tools for finding RC buggy leaf packages in testing have
found 79 potential candidates (see attached files).

The packages have been selected based on the following criteria:
 * The package had at least one RC bug without activity for the past
   14 days.
 * If a bug is assigned to multiple packages, both packages will be
   affected.
 * The RC bug affects both unstable and testing.
 * The affected package does not have any reverse dependencies in
   testing.

Normally, I would manually review[1] the list first before sending it,
but I do not have the time for that right now.  And one more time to
make sure everyone noticed it:

  *The list is unfiltered and may include entries it should not.*

If a package you care for is on this list, please consider looking into
these bugs (sooner rather than later).  This mail (unlike previous ones)
do not include a fixed deadline for these[2], but if time permits I may
follow up with deadline and a filtered list.

Fun fact: According to UDD[3], 79 RC bugs is a bit over 10% of all RC
bugs affecting Jessie.

Thanks,
~Niels

[1] We normally filter out certain type of RC bugs (incl. but not
limited to license issues), where we consider it unreasonable to demand
a resolution within the usual deadline (i.e. 14 days of "non-activity" +
7 days after a d-d notice).

[2] Note that if some of these packages block transitions, we may end up
removing them to finish the transition rather than waiting for you to
fix them.

[3]
http://udd.debian.org/bugs.cgi?release=jessie&merged=ign&fnewerval=7&rc=1&sortby=id&sorto=asc&chints=1&crttags=1

Abou Al Montacir 
   lazarus (U)

Alessio Treglia 
   gengetopt

Alexander Wirt 
   conntrack
   vlock

Andreas Tille 
   jellyfish (U)
   mira (U)

Andrew Starr-Bochicchio 
   indicator-applet (U)

Antoine Beaupré 
   charybdis

Ari Pollak 
   gltron

Arno Onken 
   rrep

Aron Xu 
   tcpcopy

Barak A. Pearlmutter 
   ivtools

Bartosz Fenski 
   httpie

Bas Wijnen 
   openmsx-catapult

Benoit Mortier 
   dapl (U)
   sdpnetstat (U)

Bradley A. Bosch 
   id-utils

Carlo Segre 
   horae

Carlos Laviola 
   lazarus

Charles Plessy 
   mira (U)

Chris Grzegorczyk 
   dnsjava

Christopher James Halse Rogers 
   gtk-nodoka-engine

Clement Lorteau 
   gtkvncviewer

Craig Small 
   pidgin-musictracker

Cristian Greco 
   qbittorrent

Daniel Kahn Gillmor 
   faketime

Daniel Leidert (dale) 
   docbook-defguide

Daniel Pocock 
   turnserver (U)

David Paleino 
   bpython
   gambas3 (U)
   gedit-valencia-plugin
   valatoys

David Stone 
   photoprint

Debian CLI Applications Team 
   monodevelop-debugger-gdb

Debian Games Team 
   xgalaga++

Debian GIS Project 
   ruby-hdfeos5

Debian KDE Extras Team 
   kwin-style-dekorator

Debian Med Packaging Team 
   clinica
   jellyfish
   mira

Debian Mozilla Extension Maintainers 

   torbutton (U)

Debian Perl Group 
   libdevel-bt-perl
   libvideo-fourcc-info-perl
   perlipq

Debian QA Group 
   lastfmsubmitd
   libpam-unix2
   pygmy

Debian Science Maintainers 
   imview-doc

Debian Science Team 
   dimbl

Debian Sympa team 
   sympa

Debian Telepathy maintainers 
   ofono

Debian VoIP Team 
   libccaudio2
   turnserver

Didier Raboud 
   kwin-style-dekorator (U)

Dirk Eddelbuettel 
   rpy

Dominic Hargreaves 
   libgeography-nationalgrid-perl
   libvideo-fourcc-info-perl (U)

Emmanuel Bouthenot 
   sympa (U)

Evgeni Golov 
   indicator-application (U)

Fernando Tarlá Cardoso Lemos 
   udisks-glue

Gambas Debian Maintainers 
   gambas3

Graziano Obertelli 
   dnsjava (U)

gregor herrmann 
   perlipq (U)

Guy Coates 
   dapl (U)
   sdpnetstat (U)

Hector Oron 
   ofono (U)

Ian Haywood 
   gambas3 (U)

Jens Peter Secher 
   sml-mode

Jo Shields 
   monodevelop-debugger-gdb (U)

Joerg Jaspert 
   vlock (U)

Jon Ludlam 
   xcp-vncterm (U)

Jonas Smedegaard 
   sympa (U)

Jonathan McDowell 
   l2tpns

Jonathan Yu 
   libvideo-fourcc-info-perl (U)

Jonny Lamb 
   ofono (U)

Joost van Baal 
   dimbl (U)

José L. Redrejo Rodríguez 
   gambas3 (U)

Julien Dutheil 
   bppsuite (U)

Jérémy Bobbio 
   torbutton

Kilian Krause 
   libccaudio2 (U)

Ko van der Sloot 
   dimbl (U)

Konstantinos Margaritis 
   ofono (U)

Kyo Lee 
   dnsjava (U)

Leonardo Robol 
   clinica (U)

Loic Dachary 
   bppsuite

Loïc Minier 
   mach

Ludovic Drolez 
   backuppc

Mario Lang 
   dapl (U)
   emacs-chess
   sdpnetstat (U)

Mark Purcell 
   libccaudio2 (U)

Mateusz Kijowski 
   mydumper

Mathieu Trudel-Lapierre 
   acct

Michael Tautschnig 
   gcc-h8300-hms

Michele Martone 
   fim

Mickael Profeta 
   prelude-lml (U)
   prelude-manager (U)

Mikolaj Izdebski 
   lbzip2

Mirco Bauer 
   monodevelop-debugger-gdb (U)

Muammar El Khatib 
   smc

Nicholas Bamber 
   libdevel-bt-perl (U)

Nicolas Bourdaud 
   eegdev

NIIBE Yutaka 
   cutter-testing-framework

Norbert Preining 
   maildir-utils

OFED and Debian Developement and Discussion 

   dapl
   sdpnetstat

Peter Howard 
   zoneminder

Peter Palfrader 
   tiobench
   vlo

Re: How should we do for font-adobe-copyrighted-fragment error?

[Niels Thykier]

On 2013-06-10 09:29, Atsuhito Kohda wrote:
> On Fri, 7 Jun 2013 17:07:09 +0200, Bastien ROUCARIES wrote:
> 
>> Le 7 juin 2013 09:28, "Atsuhito Kohda"  a
>> écrit :
>>>
>>> Yes, but it looks to me there is not practical information.
>>
>> Did you see the wiki?
> 
> Sorry for late reply.
> If you mean
> http://lintian.debian.org/tags/font-adobe-copyrighted-fragment.html
> I've seen it before but it seems, at present, I can't access it.
> 
> Antway I will read information more carefully later.
> Thanks for your explanation.
> 
> Best regards, 2013-6-10(Mon)
> 

The "wiki" would probably be [1].

As for lintian.d.o being 404 atm.  We had a technical (software-only)
problem.  The site should be back to normal in a couple of days once
lintian has had time to process the entire archive.

~Niels

[1] http://wiki.debian.org/qa.debian.org/type1nondfsg



-- 
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/51b581e7.8030...@thykier.net

Re: Mass bug filing for shared library broken symlinks detected by piuparts

[Niels Thykier]

On 2013-06-30 17:30, Dave Steele wrote:
> [...]

Thanks for working on improving Debian.

> Debian Orbital Alignment Team 
> eclipse-platform-data : eclipse
> 
> /usr/lib/eclipse/plugins/org.apache.ant_1.8.3.v20120321-1730/lib/ant-apache-resolver.jar

Looks like a false positive for this being a shared library.
  I have a feeling the particular case is just a left-over (i.e. now
unused) symlink rather than something that effects the functionality of
the package.

~Niels



-- 
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/51d051aa.6060...@thykier.net

Candidates for removal from testing (2013-06-30)

[Niels Thykier]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256


We are considering removing the following packages from testing as
they have unfixed RC bugs filed against them.  The packages can be
found in the attached dd-list.

The packages have been selected based on the following criteria:
 - The package had at least one RC bug without activity for the past
   14 days.
   - If a bug is assigned to multiple packages, both packages will
 be affected[1].
 - The RC bug affects both unstable and testing.
 - The affected package does not have any reverse dependencies in
   testing.

 - One of their RC bugs had "FTBFS" in their title. (*)
 - The source package had a popcon inst value of 500 or less. (*)

(*) These extra filter rules was applied to keep the list "down".  The
original list was 246.

If the relevant RC bugs in the affected packages (those listed in
"FTBFS-w-popcon-lt-500.txt") are not dealt with before the 8th of
July, the packages will be removed from testing.  Note that "dealt
with" may also include downgrading a severity-inflated bug or fixing
affected versions in the BTS.

For reference, the original list is also included.

Thanks,
Niels (on behalf of the Release Team)

PS: This mail has been BCC'ed to "@packages.debian.org" for
packaged listed in "FTBFS-w-popcon-lt-500.txt".

 8<  FTBFS-w-popcon-lt-500.txt  8< 

BUG [SRC]: TITLE

#712367 [bashdb]: bashdb: FTBFS: manuals build fails against textinfo5 because 
some incompatibles changes wrt 4.13 and below (some warnings have turned into 
errors)
#711787 [falconpl]: falconpl: FTBFS on mipsen
#701412 [prelude-manager]: prelude-manager: ftbfs with eglibc-2.17
#712329 [epix]: epix: FTBFS: manuals build fails against textinfo5 because some 
incompatibles changes wrt 4.13 and below (some warnings have turned into errors)
#710633 [orafce]: orafce: FTBFS: plvlex.c:209:3: error: too many arguments to 
function 'orafce_sql_yyparse'
#707399 [gedit-valencia-plugin]: gedit-valencia-plugin: FTBFS: 
GIRepository-2.0.gir:240.11-240.30: error: expected start element of `parameter'
#710614 [bip]: bip: FTBFS: lex.l:19:6: error: conflicting types for 'yyparse'
#701319 [massxpert]: massxpert: ftbfs with GCC-4.8
#701334 [openvrml]: openvrml: ftbfs with GCC-4.8
#701328 [nwchem]: nwchem: ftbfs with GCC-4.8
#701367 [toonloop]: toonloop: ftbfs with GCC-4.8
#712321 [oneliner-el]: oneliner-el: FTBFS: manuals build fails against 
textinfo5 because some incompatibles changes wrt 4.13 and below (some warnings 
have turned into errors)
#701411 [prelude-lml]: prelude-lml: ftbfs with eglibc-2.17
#701348 [rnahybrid]: rnahybrid: ftbfs with GCC-4.8
#710636 [mididings]: mididings: FTBFS: src/python_caller.cc:151:42: error: 
expected unqualified-id before numeric constant
#701438 [charybdis]: charybdis: ftbfs with eglibc-2.17
#708692 [dnsjava]: FTBFS: requires internet connectivity
#712344 [cfi]: cfi: FTBFS: Package babel Error: Unknow option `swedish'. Either 
you misspelled it
#707373 [libccaudio2]: libccaudio2: FTBFS: friends.cpp:1189:25: error: 
'ACCESS_DIRECTORY' is not a member of 'ucommon::fsys'
#701300 [ivtools]: ivtools: ftbfs with GCC-4.8
#701428 [turnserver]: turnserver: ftbfs with eglibc-2.17
#712349 [cdk]: cdk: FTBFS: This CDK release requires Ant 1.7.1 or better
#701342 [psychtoolbox-3]: psychtoolbox-3: ftbfs with GCC-4.8
#707411 [zoneminder]: zoneminder: FTBFS: zm_local_camera.cpp:742:49: error: 
invalid conversion from '__u32 {aka unsigned int}' to 'v4l2_buf_type' 
[-fpermissive]
#712327 [freepops]: freepops: FTBFS: Package babel Error: You haven't specified 
a language option.
#711628 [libhttp-daemon-ssl-perl]: libhttp-daemon-ssl-perl: FTBFS: test failure
#701317 [mailavenger]: mailavenger: ftbfs with GCC-4.8
#711367 [python-django-localeurl]: python-django-localeurl: FTBFS: 
NoReverseMatch: 'url' requires a non-empty first argument
#701298 [ion]: ion: ftbfs with GCC-4.8
#701281 [gcc-msp430]: gcc-msp430: ftbfs with GCC-4.8
#707420 [sdpnetstat]: sdpnetstat: FTBFS: strip.c:24:28: fatal error: 
linux/if_strip.h: No such file or directory
#710501 [avinfo]: avinfo: FTBFS: ass.tab.h:104:5: error: conflicting types for 
'yyparse'
#707501 [rpy]: rpy: FTBFS: grep: ecrm1095.log: No such file or directory
#708808 [nant]: nant: FTBFS: [csc] Cannot open assembly 
'/usr/lib/mono/4.0/dmcs.exe': No such file or directory.
#706176 [openjpa]: FTBFS with hsqldb 2.2.9: cannot find symbol 
(org.hsqldb.Trace)
#701308 [libpam-unix2]: libpam-unix2: ftbfs with GCC-4.8
#701416 [rrep]: rrep: ftbfs with eglibc-2.17
#710637 [sipwitch]: sipwitch: FTBFS: ../inc/sipwitch/service.h:111:14: error: 
'id' was not declared in this scope
#602668 [libdevel-bt-perl]: libdevel-bt-perl: FTBFS on armel
#707872 [elmerfem]: src:elmerfem: FTBFS in sid
#701286 [geotranz]: geotranz: ftbfs with GCC-4.8
#701356 [sdpa]: sdpa: ftbfs with GCC-4.8
#701371 [xmlcopyeditor]: xmlcopyeditor: ftbfs with GCC-4.8
#708802 [pion-net]: pion-net: FTBFS: PionScheduler.cpp:105:40: error: expected 
unqualified-id before 

Re: Candidates for removal from testing (2013-06-30)

[Niels Thykier]

On 2013-07-01 09:05, Mathieu Malaterre wrote:
> On Sun, Jun 30, 2013 at 11:32 PM, Niels Thykier  wrote:
>> #678383 [pixelmed]: pixelmed: FTBFS with Java7 (uses internal Java API)
> 
> Would it be possible to filter out (in the future?) any bugs that are
> marked as pending ? I have no control on this process.
> 
> Thanks,
> 
> 

It is technically possible to do it, but it seems a bit weird to do so.
 We are talking about RC bugs that have been tagged pending for at least
14 days with no actions taken since then.  Especially since they are
pending, it should be "trivial" to upload it in a timely fashion.

That said, your particular case is fixed in NEW and on that basis, I am
willing to take it off the list.

~Niels



-- 
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/51d1301c.5050...@thykier.net

Re: Candidates for removal from testing (2013-06-30)

[Niels Thykier]

On 2013-07-01 08:21, Lucas Nussbaum wrote:
> Hi,
> 
> Thanks a lot for this work.
> 
> On 30/06/13 at 23:32 +0200, Niels Thykier wrote:
>> We are considering removing the following packages from testing as
>> they have unfixed RC bugs filed against them.  The packages can be
>> found in the attached dd-list.
>>
>> The packages have been selected based on the following criteria:
>>  - The package had at least one RC bug without activity for the past
>>14 days.
>>- If a bug is assigned to multiple packages, both packages will
>>  be affected[1].
>>  - The RC bug affects both unstable and testing.
>>  - The affected package does not have any reverse dependencies in
>>testing.
>>
>>  - One of their RC bugs had "FTBFS" in their title. (*)
>>  - The source package had ai popcon inst value of 500 or less. (*)
>>
>> (*) These extra filter rules was applied to keep the list "down".  The
>> original list was 246.
>>
>> If the relevant RC bugs in the affected packages (those listed in
>> "FTBFS-w-popcon-lt-500.txt") are not dealt with before the 8th of
>> July, the packages will be removed from testing.  Note that "dealt
>> with" may also include downgrading a severity-inflated bug or fixing
>> affected versions in the BTS.
>>
>> For reference, the original list is also included.
> 
> Those criterias mix:
> - criterias that apply to the RC bugs (no activity for > 14 days,
>   affects testing+unstable, title contains "FTBFS")
> - criterias that apply to the source package (no rev-depends,
>   popcon<500)
> 

Yes, all of them has to apply for the bug/source to appear in the
"removal list".

> Some time ago, I experimented[1,2,3] with coming up with a list of
> criterias for "important packages" (which I just renamed to "key
> packages" to avoid the confusion with priority:important).
> Key packages are packages that must be part of our stable releases
> (= that must be in good shape to allow a Debian release).
> 
> Currently, the following criterias are used:
> | Key packages are:
> | - packages whose popcon is higher than 5% of the max popcon (that's
> |   >7570 insts currently)

In practise, we have err'ed on the side of keeping packages already at
popcon >= 1000 (possibly even lower).  When we applied the popcon <= 500
filter on the FTBFS bugs, it "only" took out about 25-30 bugs (leaving
us on 102 RC bugs).

> | OR
> | - packages of priority >= standard
> | OR
> | - packages of section debian-installer
> | OR
> | - debian-installer, debian-cd, piuparts
> | OR
> | - build-dependencies of key packages [binary dependencies are covered
> |   by the popcon criteria]
> 

Those are definitely keepers.

> [1] https://lists.debian.org/debian-devel/2013/05/msg00496.html
> [2] http://udd.debian.org/cgi-bin/key_packages.cgi
> [3] 
> http://anonscm.debian.org/gitweb/?p=collab-qa/udd.git;a=blob;f=web/cgi-bin/key_packages.cgi
> 
> I think that having such criterias, and such a list of packages, would
> be useful to better direct the work of RC bug-fixing. For example, there
> are currently 1517 RC bugs affecting sid, but only 287 RC bugs affecting
> sid's key packages. Of course, fixing all those 1517 RC bugs would be very
> nice, but we might want to focus first on the 287 bugs, as those are the
> ones really preventing Debian from being releasable.
> Typically, the "key package" criteria could be used as a filter on
> http://udd.debian.org/bugs.cgi .
> 
> Could you please comment on the criterias for key packages?  I would like
> an "OK" from the release team before adding this to bugs.cgi, so that it's
> not just "lucas made up those criterias".
> 

Well, I could be interested in using your dataset for making my life
easier for finding these candidates (i.e. reduce the amount of manual
filtering I have to do).
  It could also do as a reasonable way of producing "draft" removal
list.  I have been asked if it was possible to periodically generate a
data set that could be exposed to the PTS.  I think your script is
currently in a better shape for that purpose (even it may include
non-leaf packages).
  But I cannot comment on whether we (the Release Team) are going to
endorse it beyond that.

> Thanks,
> 
> Lucas
> 
> 

~Niels



-- 
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/51d134ee.5050...@thykier.net

Re: Candidates for removal from testing (2013-06-30) [Results]

[Niels Thykier]

I have just activated 77 removal hints - attached is a dd-list of the
packages with a removal hint now.  The list was filtered by rechecking
the severity and whether the bug still affected sid by using UDD (with a
hanful of them was manually checked as well).

Should your package still be listed despite the bug being
fixed/downgraded etc. (or if you are fixing it now), please reply to
this mail or ping me over IRC (#d-release) within the next 10 hours.

~Niels

"Adam C. Powell, IV" 
   elmerfem (U)

Alexander Reichle-Schmehl 
   ht

Alexandre Quessy 
   toonloop (U)

Andreas Tille 
   camitk (U)
   sofa-framework (U)

Arnaud Cornet 
   bip (U)

Arnaud Fontaine 
   emms

Aron Xu 
   tcpcopy

Athena Capital Research 
   pion-net

Aurélien GÉRÔME 
   dancer-ircd

Barak A. Pearlmutter 
   ivtools

Barbara "Jana" Wisniowska 
   cfi

Benoit Mortier 
   dapl (U)
   sdpnetstat (U)

Bernhard Reiter 
   python-django-threadedcomments (U)
   python-django-voting (U)

Boris Pek 
   elmerfem (U)

Chris Grzegorczyk 
   dnsjava

Chris Hanson 
   r5rs-doc

Christoph Berg 
   postgresql-pljava (U)

Damien Caliste 
   etsf-io (U)

Daniel Pocock 
   turnserver (U)

Darren Salt 
   vdr-plugin-xine (U)

David Martínez Moreno 
   glob2

David Paleino 
   gedit-valencia-plugin
   nant (U)
   valatoys

Debian CLI Applications Team 
   monodevelop-debugger-gdb
   nant

Debian Edu Packaging Team 
   kiwix

Debian GIS Project 
   ruby-hdfeos5

Debian Java Maintainers 
   openjpa

Debian Med Packaging Team 
   camitk
   clinica
   sofa-framework

Debian Multimedia Maintainers 

   clam-chordata
   toonloop

Debian Perl Group 
   libdevel-bt-perl

Debian Python Modules Team 
   django-celery
   django-floppyforms
   python-django-localeurl (U)
   python-django-threadedcomments
   python-django-voting

Debian Science Maintainers 
   elmerfem
   pynac

Debian Science Team 
   etsf-io

Debian VDR Team 
   vdr-plugin-xine

Debian VoIP Team 
   libccaudio2
   turnserver

Dirk Eddelbuettel 
   rpy

Dmitry E. Oboukhov 
   avinfo (U)

Emmanuel Promayon 
   camitk (U)

Enrico Tassi 
   freepops

Eric Dorland 
   granule

Fabrizio Regalli 
   flush

Graziano Obertelli 
   dnsjava (U)

Guy Coates 
   dapl (U)
   sdpnetstat (U)

Ian Beckwith 
   gnulib

Janos Guljas 
   python-django-localeurl

Javier Fernandez-Sanguino Pen~a 
   xorp (U)

Jens Peter Secher 
   sml-mode

Jo Shields 
   monodevelop-debugger-gdb (U)

Joachim Wiedorn 
   capi4hylafax

Jonas Smedegaard 
   toonloop (U)

Jose Calhariz 
   xorp

Julian Gilbey 
   epix

Julien Dutheil 
   bppsuite (U)

Julien Puydt 
   pynac (U)

Kartik Mistry 
   falconpl

Kilian Krause 
   libccaudio2 (U)

Kyo Lee 
   dnsjava (U)

Leo Iannacone 
   ion

Leonardo Robol 
   clinica (U)

Loic Dachary 
   bppsuite

Loïc Minier 
   mach

Luca Bruno 
   gcc-msp430

Ludovic Brenta 
   ada-reference-manual

Mario Lang 
   dapl (U)
   emacs-chess
   sdpnetstat (U)

Mark Purcell 
   libccaudio2 (U)

Matej Vela 
   libhttp-daemon-ssl-perl

Michael Fladischer 
   django-celery (U)
   django-floppyforms (U)

Michael Hanke 
   psychtoolbox-3 (U)

Michael Hanke 
   odin (U)

Michael Janssen 
   player

Michael Tautschnig 
   cbmc
   diagnostics

Miguel Landaeta 
   openjpa (U)

Mike Gabriel 
   kiwix (U)

Mirco Bauer 
   monodevelop-debugger-gdb (U)

NeuroDebian Team 
   odin
   psychtoolbox-3

Nicholas Bamber 
   libdevel-bt-perl (U)

Nicolas Delvaux 
   totem-plugin-arte

Nobuhiro Iwamatsu 
   openvrml (U)

OFED and Debian Developement and Discussion 

   dapl
   sdpnetstat

OHURA Makoto 
   oneliner-el

Oleksandr Moskalenko 
   bashdb

Peter Eisentraut 
   orafce
   postgresql-pljava

Peter Howard 
   zoneminder

Peter Palfrader 
   tiobench

Peter S Galbraith 
   gri

Petter Reinholdtsen 
   tetex-brev

Pierre-Louis Bonicoli 
   bip

Reinhard Tartler 
   aspectc++

Roberto C. Sanchez 
   pion-net (U)

Roberto Lumbreras 
   geotranz

Sam Hocevar (Debian packages) 
   openvrml

Stanislav Maslovski 
   avinfo

TANIGUCHI Takaki 
   clam-chordata (U)

Thomas Bushnell, BSG 
   ifhp
   jacal

Thomas Günther 
   vdr-plugin-xine (U)

Thomas Schmidt 
   vdr-plugin-xine (U)

Tobias Grimm 
   vdr-plugin-xine (U)

Ulises Vitulli 
   mailavenger

Vagrant Cascadian 
   zoneminder (U)

Vasudev Kamath 
   falconpl (U)
   kiwix (U)

Yann Dirson 
   fweb

Yaroslav Halchenko 
   odin (U)
   psychtoolbox-3 (U)
   remake

Youhei SASAKI 
   ruby-hdfeos5 (U)

Re: Candidates for removal from testing (2013-06-30) [Results]

[Niels Thykier]

On 2013-07-08 01:34, Andreas Tille wrote:
> Hi,
> 
> On Mon, Jul 08, 2013 at 01:10:51AM +0200, Niels Thykier wrote:
>>
>> Andreas Tille 
>>camitk (U)
> 
> A fixed version is since two days in
>http://ftp-master.debian.org/new.html
> 
> 
> Thanks for your QA effort
> 
>  Andreas.
> 

Thanks for catching that, I have removed it from the list of hints.

~Niels



-- 
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/51d9fd9d.8000...@thykier.net

Re: UTF-8 in jessie

[Niels Thykier]

On 2013-08-12 04:18, Charles Plessy wrote:
> Le Mon, Aug 12, 2013 at 02:51:52AM +0200, Adam Borowski a écrit :
>>
>> I would like to propose full UTF-8 support.  I don't mean here full
>> support for all of Unicode's finer points, merely complete eradication of
>> mojibake.
> 
> Hi Adam,
> 

Hi,

> this is a great goal.  Here are two comments.
> 
> There is a related issue opened on the Policy 
> (),
> where we propose the following:
> 
>  - Require UTF-8 for the names of all files and directories installed by 
> binary packages.

For the record, there is a Lintian tag for this now[1], which suggests
only a handful of packages violates this.

>  - Recommend ASCII when possible.
>  - Require ASCII for files in /bin, /sbin, /usr/bin, /usr/sbin and /usr/games.
> 

Requiring ASCII for files in $PATH should be trivial to implement as a
separate tag.  I suppose the ASCII requirement could also be implemented
as a pedantic check or so.  Regardless, patches welcome.  :)

> About display by GUIs, I think that we should have a system to install all the
> fonts necessary to display languages that we support at the installation.
> 
> Have a nice Debconf !
> 

~Niels

[1] http://lintian.debian.org/tags/file-name-is-not-valid-UTF-8.html


-- 
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/520895a6.1090...@thykier.net

Re: Introducing dgit - git integration with the Debian archive

[Niels Thykier]

On 2013-08-23 19:17, Ian Jackson wrote:
> Ian Jackson writes ("Re: Introducing dgit - git integration with the Debian 
> archive"):
> ...
>> If I have understood you, dgit won't work properly if you make the
>> "wrong" kind of change, so I need to either have this fixed, or (more
>> likely) to work around it (and bitch some more in the manpage).  Does
>> "dpkg-source --commit" make any changes other than to quilt metadata ?
>> Perhaps dgit push should do that automatically.
> 
> Does anyway know of a `3.0 (quilt)' format package whose maintainer
> wouldn't mind a bunch of crazy (perhaps abortive) NMUs to
> experimental, which I can therefore use for testing ?  I promise not
> to upload to sid by mistake.
> 
> Volunteers welcome :-).
> 
> Ian.
> 
> 

If you promise to add autopkgtest for it, you can use any of my
packages[1]. :P

~Niels

[1] Any of which I am the sole maintainer.  E.g. mscgen.



-- 
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/52179c67.7010...@thykier.net

Roll call for porters of architectures in sid and testing

[Niels Thykier]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi,

As we announced in [LAST-BITS], we would like to get a better idea of
that status of the ports, to make an informed decision about which
port can be released with jessie. One of the steps is to get an
overview of which of the porters are (still) active for each
port. Once the results from the role-call are in, we will request
other information about the status of the ports. In the meantime, feel
free to update and collect info about the ports in the Debian wiki[WIKI].

If you are (or intend to become) an active porter for the lifetime of
jessie, then please send a signed email explaining your involvement in
the port to the Release Team  before
1st of October 2013. Please explain the level of your involvement in
the port.

Feel free to use the following template as your reply:

"""
  Hi,
  
  I am an active porter for the following architectures and I intend
  to continue this for the lifetime of the jessie release:

  For , I
  - test (most|all) packages on this architecture
  - fix toolchain issues
  - triage arch-specific bugs
  - fix arch-related bugs
  - maintain buildds
  - ...
  
  
  
  
"""

Niels, on behalf of the release team

[LAST-BITS] http://lists.debian.org/debian-devel-announce/2013/08/msg6.html

[WIKI] https://wiki.debian.org/ArchiveQualification/Jessie

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

iQIcBAEBCAAGBQJSIu2TAAoJEAVLu599gGRC86EP/j/7FEZ9pxpTEHrBI41GTu6r
nENS5kAZAuxFQHfYLtKexBcgneGd6cgdmr3cIoh1ZL9lJgXq74X8FL5IbWNqUw9S
o9UQWpZJiwIIlH4fqSgFVLIphI0DQr7dXI7xcDIm4kl6Fdruo1tGxX8xqL23jzdP
nQb3jrXv3bj5943MfWeCbODILv2N6qev9VtWeQ6Wmh8PvxRUl7VqgdQaeHtlMsUp
TQT5fz0cw8gc2amlwlOZxaGDV2C8mHboJIKMEsu79BK4SlFSED9rXn4juFPUnAgG
uADsMdBBqEIgSMN42cPHQju+KLfJe/+xScmlzzDS/d7aWWs02TibcQ1ZnPi+bcgp
bd/Wa0lms+Fc2OpcuFle9Lwo+2B+ka1Dd3itm+D0SbmrxoGi6CuMMwydLcQbSJ73
hHw9HJEIQr2x/ZItNPJrSvvj50rwYXcmFbxtVAwv2pFXfQ37iukYgAaaMvnwpNNJ
6dM1coCF9skNkXLO8rkZ+5aupGgjpS9BdKKAEQrPy/aoaW9KNCZrLQeA4C3QySBU
OcCNBv7taSjVAVNszKtRIQpu2gzFGAV0u9Gj41qW1JzDHYrmAvMyGxrndOxTmaFr
p05QWgcMsPhNvdHjd6sWLyzJ5NYUKksCPMRgCc0BEd6moIyrt7UFsp2+guJZPBJ0
pffEJGK2iGtrWmJfElof
=TUeZ
-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/20130901073351.a92862...@thykier.net

Re: Less dinstall FTW?

[Niels Thykier]

On 2013-09-06 15:02, Helmut Grohne wrote:
> Thanks for your explanations!
> 
> On Thu, Aug 29, 2013 at 02:39:09PM +0200, Ansgar Burchardt wrote:
>> As this suite is much smaller than the full archive, updating it can be
>> done with much less overhead and is done with every cron.unchecked
>> run. Packages.gz (amd64) is just 98 kb, Sources.gz is 180 kb compared to
>> 8.5 MB each for the main archive. There are also no Contents indices.
> 
> One aspect I couldn't find in the discussion so far is reduction of
> bandwidth on *my* end. Let us for a moment consider a user to run sid
> with incoming enabled and the dinstall frequency cut in half. Are the
> following conclusions correct?
> 
>  * [...]
>  * If PDiffs are enabled, I assume that incoming would not support
>PDiffs for its rapid rate of change. With PDiffs the number of diffs
>is interesting, because processing them usually is the limiting
>factor here. The number of PDiffs would be halved as well here, so
>the update would usually go faster.
> 
> [...]
> 
> Who hasn't disabled PDiffs, because they take way too long when the
> network is fast?
> 

Well, most of the problem with PDiffs could actually go away if made a
(to me seemly) minor change their index files.  If it is possible to
determine the "outcome" of applying a PDiff, APT could apply the diffs
in a much more efficient manner.  Currently, apt-file does this by
making assumptions (which holds for DAK produced PDiffs atm, but not for
- I think - reprepro).
  So if "runtime of using PDiff" is your concern, I think "fixing"
PDiffs would be a much more interesting solution than working around it
by halfing the number of dinstalls  (although, I don't have particularly
strong opinions in regards 2 vs 4 dinstalls per day).

For those interested, I believe #703366 might be worth a read on that
topic[1].

>>From this very limited POV the proposal appears to be an improvement.
> 
> Helmut
> 
> 

~Niels

[1] e.g. <201303201830.32577...@sfritsch.de>



-- 
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/5229d53c.4020...@thykier.net

Re: detecting autopkgtest

[Niels Thykier]

On 2013-09-16 10:38, Enrico Tassi wrote:
> Hello, is checking for the environment variable ADTTMP the recommended
> way to test if a test is being run by adt-run?  It seems to work, but
> I'd like to know if there is a better way or not.
> 
> I've many packages with a decent "test" target already, run at build
> time.  In case this target is run by adt-run I want it to behave in
> a slightly different way.  For exmample I don't want to set env
> variables so that non system-wide installed .so files are found,
> something really needed when running the tests at build time.
> 
> Cheers
> 

Hey,

Personally, I just added a small sh script to set a few ENV variables
then called the upstream test target (see [1]).

~Niels

[1]
http://anonscm.debian.org/gitweb/?p=lintian/lintian.git;a=blob;f=debian/tests/testsuite;h=8226c94f18c9007b74205263d0f2c61bcfdaed32;hb=beb1094db955fd99b693fca1e4c87958676dfe74



-- 
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/5236c891.8080...@thykier.net

Re: Roll call for porters of architectures in sid and testing (Status update)

[Niels Thykier]

On 2013-09-01 09:33, Niels Thykier wrote:
> Hi,
> 
> As we announced in [LAST-BITS], we would like to get a better idea of
> that status of the ports, to make an informed decision about which
> port can be released with jessie. One of the steps is to get an
> overview of which of the porters are (still) active for each
> port. Once the results from the role-call are in, we will request
> other information about the status of the ports. In the meantime, feel
> free to update and collect info about the ports in the Debian wiki[WIKI].
> 
> If you are (or intend to become) an active porter for the lifetime of
> jessie, then please send a signed email explaining your involvement in
> the port to the Release Team  before
> 1st of October 2013. Please explain the level of your involvement in
> the port.
> 
> Feel free to use the following template as your reply:
> 
> [...]
> 
> Niels, on behalf of the release team
> 
> [LAST-BITS] 
> http://lists.debian.org/debian-devel-announce/2013/08/msg6.html
> 
> [WIKI] https://wiki.debian.org/ArchiveQualification/Jessie
> 


Hi all,

Here is a little status update on the mails we have received so far.
First off, thanks to all the porters who have already replied!

So far, the *no one* has stepped up to back the following architectures:

   hurd-i386
   ia64
   mips
   mipsel
   s390x

I have pinged some people and #d-hurd, so this will hopefully be amended
soon.  Remember that the *deadline is 1st of October*.

In the list above, I excluded:

  amd64 and i386: requirement for porters is waived
  s390: Being removed from testing during the Jessie cycle
(Agreement made during the Wheezy release cycle)

The following table shows the porters for each architecture in
*unstable* that I have data on so far:

armel: Wookey (DD)
armhf: Jeremiah Foster (!DD, but NM?), Wookey (DD)
kfreebsd-amd64: Christoph Egger (DD), Axel Beckert (DD),
   Petr Salinger (!DD), Robert Millan (DD)
kfreebsd-i386: Christoph Egger (DD), Axel Beckert (DD),
   Petr Salinger (!DD), Robert Millan (DD)
powerpc: Geoff Levand (!DD), Roger Leigh (DD)
sparc: Axel Beckert (DD), Rainer Herbst (!DD)


If you are missing from this list above, then I have missed your email.
 Please follow up to this mail with a message-ID (or resend it,
whichever you prefer).

We also got a number of people interested in architectures not currently
in unstable.  These are:

  alpha: Bill MacAllister (!DD), Kieron Gillespie (!DD)
  arm64: Wookey (DD)
  parisc/hppa: Helge Deller (!DD)
  ppc64: Steven Gawroriski (!DD)
  sparc64: Steven Gawroriski (!DD), Kieron Gillespie (!DD)

This will hopefully teach me to remember to include the "in unstable"
restriction to the next "roll call".  :)  Anyhow, if you are working on
these architectures on debian-ports and saw a new name in the list
above, this might be an opportunity to recruit new people.


We also received a couple of emails from people who are not or did not
want to be porters at the moment.  However, they expressed an interest
in the architectures:

  David Kuehling: mipsel
- debug arch-related issues
  Meelis Roos: ppc, sparc64 (parisc)
- test and report bugs in upstream kernel
  Peter Green: armhf (possibly any-arm)
- works on raspbian


In the template email included in the roll call, we included some tasks
that people might be doing.  These are the task people have said they
are doing for a given port.

  * test packages: armhf, kfreebsd-amd64 (x4), kfreebsd-i386 (x4),
 powerpc, sparc (x2)
  * fix toolchain issues: armhf, powerpc
  * triage arch-specific bugs: armhf, kfreebsd-amd64 (x3),
 kfreebsd-i386 (x3), powerpc, sparc (x2)
  * fix arch-related bugs: armhf, kfreebsd-amd64 (x3),
  kfreebsd-i386 (x3), powerpc
  * maintain buildds: armhf, kfreebsd-amd64, kfreebsd-i386

NB: I have manually translated some prose-text into the items above, so
something might have been lost (or gained) in that translation.

Some of the porters also added some new items.  I have included some of
these items below:

  + test d-i "when needed": powerpc (x2)
  + maintain arch-related pkgs: kfreebsd-amd64, kfreebsd-i386
  + maintain non-DSA porter box: kfreebsd-amd64
  + maintain production system of $arch: sparc/stable
  + can offer hardware access[1]: sparc (Axel Beckert)
  + eglibc issues: kfreebsd-amd64, kfreebsd-i386
  + maintain+test cross-toolchains for $arch: armel, armhf

~Niels

[1] Restrictions may apply.


-- 
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/523ab805.7000...@thykier.net

Re: Upcoming changes in Tcl/Tk packaging

[Niels Thykier]

On 2013-09-25 11:38, Cyril Brulebois wrote:
>> > 3. Renaming tcl-dev and tk-dev into libtcl-dev and libtk-dev. Since
>> > too many packages have versioned build-dependencies on tcl-dev or
>> > tk-dev, I chose to retain tcl-dev and tk-dev packages (as
>> > meta-packages which depend on libtcl-dev and libtk-dev). Switching to
>> > libtcl-dev and libtk-dev can be gradual. Would adding a lintian
>> > warning discouraging to use the old names possible?
> Same as above: creating work for no actual benefit.
> 
> If that was triggered by some lintian warnings, just override them and
> be done with it. Lintian isn't here to generate work.
> 
> Mraw,
> KiBi.

Actually, I think Sergi wanted to add a Lintian warning for using the
old names (IANSergi, so it is just a guess).  At least I am pretty sure
Lintian does not have a tag for renaming -dev packages (the only thing I
can think of is the "pkg name does not match SONAME"-tag, but it doesn't
seem to apply here).
  FTR, that is pretty trivial to mark packages "obsolete" in Lintian.
It simply requires adding the package names to the Lintian data file
called "data/fields/obsolete-packages".  (Though, that is not a remark
about whether the renaming should be done in this case)

~Niels



-- 
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/5242b354.5000...@thykier.net

Re: Bits from the Release

[Niels Thykier]

On 2013-09-03 13:49, Stefano Zacchiroli wrote:
> On Sun, Aug 25, 2013 at 05:09:22PM +0200, Niels Thykier wrote:
>> How you can help (NEW-TEST-HELP) 
>> 
>> 
>> Add tests to your packages.  The full specification for these
>> tests are available from [AUTOPKG].  If you need inspiration,
>> consider looking at some of the existing
>> autopkgtests[FIND-AUTOPKG].
>> 
>> We need to have the autopkgtest tests run.  Holger Levsen
>> suggested that jenkins.debian.net has the necessary hardware to
>> support these tests.
>> 
>> Asheesh Laroia has kindly spent some time during DebConf13
>> researching and experimenting with setting up such jobs.
> 

Hi,

I realise we had a chat about this on IRC, but I never got around to
follw up to your mail, so here goes:

> So, in the context of work to periodically run various sorts of
> static analysis tests on Debian packages [1], we (myself, Sylvestre
> Ledru, Léo Cavaillé, and Matthieu Caneill) have considered using
> Jenkins.  Based on feedback from Matthias Klumpp and his experience
> in using Jenkins for Tanglu, we have concluded that it didn't
> really scale to the point that we needed (number of Debian packages
> * number of checkers). We ended up using Paul Tagliamonte's debile
> infrastructure [2].
> 
> I don't doubt that jenkins.d.n can be leveraged for the time
> being, giving the low amount of autopkgtests currently available.
> But you might want to check with Matthias or similar experiences
> before committing to using Jenkins for this.
> 

Assuming there is sufficient hardware behind debile (I was told this
wasn't a problem for jenkins.d.n), then I would (personally) welcome a
debile-based setup instead of a jenkins-based one for this.  Honestly,
I do not think the Release Team cares much about the underlying
platform, as long as the platform and the autopkgtest-runner have
active maintainers.
  To my knowledge, there has not been anyone volunteers in this area
yet since Asheesh spent his time at DebConf13 on a prototype[1].
Volunteering for this task is left as an exercise for the reader.

> 
> Apart from this, hopefully useful feedback: kudos for these saucy
> bits from the Release Team :-) Keep up the good work!
> 
> 
> Cheers.
> 
> [...]

You are welcome.  Hopefully we will have some new "saucy bits" fairly
soon.

~Niels

[1] At least not anyone on debian-release@l.d.o



-- 
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/5242d6e3.8010...@thykier.net

Re: Automatic removal of packages from testing

[Niels Thykier]

On 2013-09-30 17:33, Tshepang Lekhonkhobe wrote:
> On Mon, Sep 30, 2013 at 5:13 PM, Joey Hess  wrote:
>> Niels Thykier wrote:
>>> [KEY-PACKAGES]
>>> http://udd.debian.org/cgi-bin/key_packages.yaml.cgi
>>
>> If you're curious, as I was, how this list is arrived at, here's the
>> source:
>>
>> http://anonscm.debian.org/gitweb/?p=collab-qa/udd.git;a=blob;f=scripts/update-key-packages;h=d214dcbbe4aea5b2b49b132a0c135dfef40cf71f;hb=6743df0478511a99f4d779db8229a92a0d938da3
>>
>> Basically, 5% of popcon submitters have it installed, or it's part of
>> debian-installer, or something debian-cd includes on CDs (including
>> task packages).
> 
> Thanks for the link; I was also curious, but a quick search didn't
> help. I just assumed it was discussed on debian-release, which I don't
> read.
> 
> 

The idea behind and the source code for finding "key packages" were also
mentioned in our last "Bits" mail to debian-devel-announce[1].
Hopefully there weren't to many surprises (or differences) here.  :)

~Niels

[1] https://lists.debian.org/debian-devel-announce/2013/08/msg6.html

Quote:
"""
> At the Release BoF at DebConf13, it was suggested to use (something
> based on) Lucas Nussbaum's "key packages" proposal.  The original
> proposal can be seen at [KEY-PKGS].
> [...]
> [KEY-PKGS]
> https://lists.debian.org/debian-devel/2013/05/msg00496.html
> http://udd.debian.org/cgi-bin/key_packages.cgi (NB: This script has a long 
> load time)
> source: 
> http://anonscm.debian.org/gitweb/?p=collab-qa/udd.git;a=blob_plain;f=web/cgi-bin/key_packages.cgi;hb=HEAD
"""


-- 
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/52499d49.7070...@thykier.net

Re: automake transition breakages

[Niels Thykier]

On 2013-09-30 20:38, Eric Dorland wrote:
> * Russ Allbery (r...@debian.org) wrote:
>> Cyril Brulebois  writes:
>>> Julian Taylor  (2013-09-30):
>>
 At minimum the packages using Werror should be test rebuilt before each
 new upload:
 http://codesearch.debian.net/search?q=AM_INIT_AUTOMAKE.*-Werror
>>
 The list is small enough that it can be done by hand / small script.
>>
>>> So that they stop using Werror? Good idea.
>>
>> I use -Werror for Automake for all of the packages for which I'm upstream
>> and have not noticed it being a serious issue, although maybe I'm missing
>> something?  But I didn't have any trouble regenerating the files for my
>> various packages with Automake 1.14.
> 
> The one that's been biting people is there's a new warning for
> configure.in being deprecated. So for a well maintained package or a
> good upstream this isn't going to be a problem.
>  
>> [...]
> 

For the record, Lintian should have a check for this[1].  From what we
can detect (assuming no false-positives), we got about 1.2k packages
using configure.in with automake (I guess most of them are not using
-Werror).  Anyhow, 

~Niels

[1] http://lintian.debian.org/tags/deprecated-configure-filename.html



-- 
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/5249c71f.4080...@thykier.net

Results of the porter roll call (Was: Roll call for porters of architectures in sid and testing)

[Niels Thykier]

Hi,

The final results are in:

Summary table:
Arch   || DDs || NMs/DMs || Other || Total
---++-++-++---++--
armel  ||  3  ||   0 || 1 ||4
armhf  ||  3  ||   1 || 2 ||6
hurd-i386  ||  5  ||   0 || 3 ||8
ia64   || *0* ||   0 || 3 ||3
kfreebsd-amd64 ||  4  ||   0 || 2 ||6
kfreebsd-i386  ||  4  ||   0 || 2 ||6
mips   ||  1  ||   0 || 1 ||2
mipsel ||  1  ||   0 || 1 ||2
powerpc[1] || (1) ||   0 || 2 ||   2.5?
s390x  || *0* ||   0 || 0 ||   *0*
sparc[2]   ||  1  ||   0 || 0 ||1

[1] The (1) and .5 is from a "I am not primarily a porter [...]"-remark,
so I wasn't sure how to count it.

[2] By the looks of it, if sparc was replaced by sparc64, we could be
looking at 3 in the "Other"-column rather than 0.

NMs/DMs include DMs and people currently in NM process.  The "Other"
column may include people who said they would like to become porters
(but would need to be introduced to the job) and thus may imply some
active recruiting from the current porters.  This is at least true for
hurd-i386.



The current policy says that we require "5 developers" (i.e. DDs) for
release architectures[AP], so based on that only amd64, i386 and
hurd-i386 would pass this requirement.  It is quite possible we need to
revise that requirement, but most of the architectures would (still) do
well to attract a few more (DD) porters.
  I have attached a file with my notes of who are behind those numbers.
 If your name is missing or you believe I have miscounted something[CD]
for an architecture listed in the table above, please reply to this
email *promptly* (CC'ing me explicitly is fine) with your concerns or
corrections.

At this time, I have *not* updated the arch qualification table yet.  I
will do that in a couple of days.  We will also follow up on this in the
next bits from the release team.

~Niels

[AP] http://release.debian.org/jessie/arch_policy.html

[CD] I may (or may not) have been caffeine-deprived when I did the
counting.  You are free to make assumptions about whether that has
affected my ability to do addic^Htion or parsing your email(s) properly.

Summary table:
Arch   || DDs || NMs/DMs || Other || Total
---++-++-++---++--
armel  ||  3  ||   0 || 1 ||4
armhf  ||  3  ||   1 || 2 ||6
hurd-i386  ||  5  ||   0 || 3 ||8
ia64   || *0* ||   0 || 3 ||3
kfreebsd-amd64 ||  4  ||   0 || 2 ||6
kfreebsd-i386  ||  4  ||   0 || 2 ||6
mips   ||  1  ||   0 || 1 ||2
mipsel ||  1  ||   0 || 1 ||2
powerpc[1] || (1) ||   0 || 2 ||   2.5?
s390x  || *0* ||   0 || 0 ||   *0*
sparc  ||  1  ||   0 || 0 ||1

[1] Roger Leigh: "I am not primarily a porter [...]".

armel: Wookey (DD), Gatis Visnevskis (!DD), Nobuhiro Iwamatsu (DD), Steve 
McInture (DD)
armhf: Jeremiah Foster (!DD, but NM?), Wookey (DD), Justus Winter (!DD), 
Lennart Sorensen (!DD), Nobuhiro Iwamatsu (DD), Steve McInture (DD)
hurd-i386: Samuel Thibault (DD), Barry deFreese (DD), Thomas Schwinge (!DD), 
Pino Toscano (DD), Svante Signell (!DD), Michael Banck (DD), Guillem Jover 
(DD), Zhang Cong (!DD)
kfreebsd-amd64: Christoph Egger (DD), Axel Beckert (DD), Petr Salinger (!DD), 
Robert Millan (DD), Steven Chamberlain (!DD), Guillem Jover (DD)
kfreebsd-i386: Christoph Egger (DD), Axel Beckert (DD), Petr Salinger (!DD), 
Robert Millan (DD), Steven Chamberlain (!DD), Guillem Jover (DD)
mips: Graham Whaley (!DD), Andreas Barth (DD)
mipsel: Graham Whaley (!DD), Andreas Barth (DD)
powerpc: [Roger Leigh (DD)], Geoff Levand (!DD), Lennart Sorensen (!DD)
sparc: Axel Beckert (DD)

Maybes for ia64 (?): Martin Lucina (!DD), Émeric MASCHINO (!DD), Mark Wickens 
(!DD)


(Some inaccuracies can occur in the (xN) below; /me got confused and may have 
lost count for some of them)

Items suggested in the roll call:
* test packages: armel (x3), armhf (x4), hurd-i386 (x4), kfreebsd-amd64 (x6), 
kfreebsd-i386 (x6), mips, mipsel, powerpc (x3), sparc
* fix toolchain issues: armel, armhf (x3), hurd-i386 (x3), mips, mipsel, 
powerpc (x2)
* triage arch-specific bugs: armel (x3), armhf (x4), hurd-i386 (x4), 
kfreebsd-amd64 (x5), kfreebsd-i386 (x5), mips (x2), mipsel (x2), powerpc (x2), 
sparc
* fix arch-related bugs: armel (x2), armhf (x4), hurd-i386 (x5), kfreebsd-amd64 
(x5), kfreebsd-i386 (x5), mips (x2), mipsel (x2), powerpc (x2)
* maintain buildds: armhf, hurd-i386 (x2), kfreebsd-amd64, kfreebsd-i386, mips, 
mipsel

Items suggested by porters in their mails:
+ test d-i "when needed": hurd-i386, powerpc (x3)
+ maintain arch-related pkgs: kfreebsd-amd64, kfreebsd-i386
+ maintain non-DSA porter box: hurd-i386 (x2), kfreebsd-amd64
+ maintain production system of $arch: sp

First autoremovals happen in about 8 days

[Niels Thykier]

Hi,

This is a friendly reminder.  If you are listed below, then the listed
packages of yours will be automatically removed from testing within 15
days.  The "first batch" of automatic removals will happen in about 8
days.

Please remember that "fixing" your RC bug(s) can sometimes be as
simple as correcting the metadata of the bugs (see also #725321[0]) or
(where inflated) downgrade the severity of the bug.

This mail was a "one-time public service annoucement"; I *do not*
intend to send out "reminders" in the future.  Remember that you can
pull the same data from [1] or [2].

~Niels

[0] You may (or may not) find the following blog post about the BTS
interesting as well:

  http://rhonda.deb.at/blog/debian/on-BTS-usage.html

It is admittedly more focused on stable, but some of the remarks may
still apply to bugs filed against your package.  That post can (also)
help you clean up your package's BTS page and ensuring that your
packages have no open RC bugs still affecting stable.

[1] http://udd.debian.org/cgi-bin/autoremovals.cgi

[2] http://udd.debian.org/cgi-bin/autoremovals.yaml.cgi


   8<  8<  8< 

"Adam C. Powell, IV" 
   babel: bugs 723789, flagged for removal in 12.7 days

A Mennucc1 
   wfrog: bugs 717328, flagged for removal in 8.3 days

AGOSTINI Yves 
   libjifty-plugin-comment-perl: bugs 720789, flagged for removal in 8.3 days
   libjifty-plugin-oauth-perl: bugs 720791, flagged for removal in 8.3 days
   libjifty-plugin-wikitoolbar-perl: bugs 720792, flagged for removal in 8.3 
days

Adrian Knoth 
   timemachine: bugs 713592, flagged for removal in 8.3 days

Agney Lopes Roth Ferraz 
   hardinfo: bugs 713717, flagged for removal in 8.3 days

Al Nikolov 
   trac-datefieldplugin: bugs 714985, flagged for removal in 8.3 days
   trac-icalviewplugin: bugs 714985, flagged for removal in 8.3 days
   trac-wikitablemacro: bugs 714985, flagged for removal in 8.3 days

Alastair McKinstry 
   gramadoir: bugs 723881, flagged for removal in 13.7 days

Alejandro Garrido Mota 
   libnet-dri-perl: bugs 710954, flagged for removal in 8.3 days

Alessandro De Zorzi 
   libapache2-mod-ruid2: bugs 709465, flagged for removal in 8.3 days
   phamm: bugs 669841, flagged for removal in 8.3 days

Alessio Treglia 
   din: bugs 718165, flagged for removal in 8.3 days
   jack-rack: bugs 705053,713468, flagged for removal in 8.3 days
   lv2proc: bugs 713715, flagged for removal in 8.3 days
   mp3fs: bugs 713614, flagged for removal in 8.3 days
   timemachine: bugs 713592, flagged for removal in 8.3 days
   transmageddon: bugs 713205, flagged for removal in 8.3 days

Alexander Reichle-Schmehl 
   nagvis: bugs 709956, flagged for removal in 8.3 days

Alexander Wirt 
   hotkeys: bugs 713671, flagged for removal in 8.3 days
   nagvis: bugs 709956, flagged for removal in 8.3 days
   nsca: bugs 721644, flagged for removal in 8.3 days
   vlock: bugs 702705, flagged for removal in 11.2 days

Alexandre Quessy 
   supercollider: bugs 713670, flagged for removal in 8.3 days

Anders Lennartsson 
   setpwc: bugs 717129, flagged for removal in 8.3 days

Andreas Barth 
   dpkg-sig: bugs 723867, flagged for removal in 13.4 days

Andreas Hildebrandt 
   ball: bugs 720681,718144, flagged for removal in 8.3 days

Andreas Rottmann 
   g-wrap: bugs 713203, flagged for removal in 8.3 days

Andreas Tille 
   gdpc: bugs 713652, flagged for removal in 8.3 days
   gwyddion: bugs 713565, flagged for removal in 8.3 days
   praat: bugs 713597, flagged for removal in 8.3 days
   r-other-mott-happy: bugs 709190,713284, flagged for removal in 8.3 days

Andrei Zavada 
   aghermann: bugs 713574, flagged for removal in 8.3 days

Andres Mejia 
   vdpau-video: bugs 713612, flagged for removal in 8.3 days

Andrew Lee (李健秋) 
   lxappearance-obconf: bugs 722112, flagged for removal in 8.3 days
   lxlauncher: bugs 722110, flagged for removal in 8.3 days
   scim-chewing: bugs 707442, flagged for removal in 8.3 days

Andrew McMillan 
   davical: bugs 717043, flagged for removal in 8.3 days

Andrey Rahmatullin 
   mpdscribble: bugs 710066, flagged for removal in 8.3 days

Andy Spencer 
   aweather: bugs 713613, flagged for removal in 8.3 days

Angel Abad 
   libjavascript-packer-perl: bugs 711629, flagged for removal in 8.3 days

Ansgar Burchardt 
   libjavascript-packer-perl: bugs 711629, flagged for removal in 8.3 days

Arjan Oosting 
   drift: bugs 713313, flagged for removal in 8.3 days

Ask Hjorth Larsen 
   python-ase: bugs 717989, flagged for removal in 8.3 days

Atsuhito KOHDA 
   texmacs: bugs 711383, flagged for removal in 8.3 days

Aurelien Jarno 
   kfreebsd-8: bugs 720470,717959,720476, flagged for removal in 14.7 days

Barry deFreese 
   plee-the-bear: bugs 720819, flagged for removal in 8.3 days

Bart Martens 
   pipewalker: bugs 713336, flagged for removal in 8.3 days

Ben Pfaff 
   pspp: bugs 720865, flagged for removal in 8.3 days

Ben Webb 
   libsru-perl: bugs 720357, flagged for removal in 8.3 days

Benjamin Mako Hill 
   mos

Re: First autoremovals happen in about 8 days

[Niels Thykier]

On 2013-10-06 13:09, Steven Chamberlain wrote:
> Hi,
> 
> On 06/10/13 08:52, Niels Thykier wrote:
>>kfreebsd-8: bugs 720470,717959,720476, flagged for removal in 14.7 days
> 
> Not sure why that's appearing in this list because:
> 1. the package was removed from testing over a month ago at the request
> of the maintainer, and
> 2. when that happened the bugs listed were closed?
> 
> Perhaps this is because the script does not notice 1. and therefore
> despite 2. it still thinks affected versions are in testing?
> 
> Regards,
> 

Hey,

Thanks for reporting this.

It looks like this is caused by kfreebsd-8 being marked with
"Extra-Source-Only: yes", presumably because something lists it in
"Built-Using".  For most parts it means the package is already removed
but not all tools seem to recognise this e.g. the PTS, the BTS
(allegedly) and by extension the auto-removal script.

~Niels



-- 
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/52518ce2.9010...@thykier.net

Re: First autoremovals happen in about 8 days

[Niels Thykier]

On 2013-10-08 00:04, Bill Allombert wrote:
> [...]
> 
> So while it is possible that the _maintainer_ is not needing a friendly
> remainder, other interested third-party might.
> 
> Cheers,
> Bill.
> 
> 

Hi,

I, genuinely, hope that these removals-warnings will make people fix
bugs pro-actively rather than reactive.  From my PoV, more visibility
and focus on these bugs is welcome.  However, I know from experience
that I will not be able to maintain a manual "friendly reminder" (at
least not in a timely/reliable fashion), which is why I made this a
one-time thing.
  You (as in anybody) are more than welcome to implement a
weekly-reminder thing or so.  Not sure if people would welcome such a
thing on debian-devel, but having some way of at least opt-in on such a
reminder/warning would be a great idea.

That said, as much as I think it is a great idea I cannot volunteer to
do it.  I already have a sufficient "d-release" backlog ... :-/  Even
the current implementation was "out-sourced".
  On a related note, kudos to Ivo De Decker for being the "Do'er" behind
automatic removals!

~Niels



-- 
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/52554881.7060...@thykier.net

Re: Bits from the Release Team (Jessie freeze info)

[Niels Thykier]

On 2013-10-13 19:24, Thomas Goirand wrote:
> Hi Niels,
> 

Hi,

> First of all, thanks a lot for planning this well in advance. Much
> appreciated. This changes a lot compared to what happened in NYC! :)
> 

You are welcome, :)

> On 10/13/2013 11:01 PM, Niels Thykier wrote:
>>
>> Freeze date and Freeze Policy for Jessie
>> 
>>
>> We are happy to announce that we will freeze Jessie at 23:59 UTC on
>> the 5th of November 2014.
> 
> This date is surprising me. I thought we would have the same freeze date
> every 2 years, so I was expecting late June 2014, 2 years after the
> freeze of Wheezy. Wasn't this announced previously?
> 

Personally, I backed a freeze in November 2014 because I wanted to aim
for a <= 2 year release cycle.  This (at most) 2-year estimate includes
an 18 month development period and a(n up to) 6 month freeze.
Obviously, if the freeze is shorter than 6 months, great!
  Having 2 years between every freeze date would make sense if we could
keep our freezes shorter than 6 months.  It could hopefully also
motivate people into making the freezes shorter (giving us a slightly
longer development cycle).
  But if our freezes are 10 months, then "2-years between freeze-dates"
leaves us with only 14 months of development.  Of which, the Release
Team would be spending 4-5 months recuperating from the last freeze
(based on the past year).

> Just right after Ubuntu had it's LTS out seemed to be a good moment. In
> fact, synchronizing the Debian freeze date with the Ubuntu LTS would
> have been even better, IMO (or the Ubuntu freeze date for the next LTS).
> 

I think our first priority should be getting back in control of our
freezes and the length thereof.

> Why the 5th of November 2014? Why beginning of November? Why the 5th and
> not the 4th or 6th? In other words: what's the reasoning behind this date?
> 
> Cheers,
> 
> Thomas
> 
> 

We picked the 5th over another date in November because it was believed
the 5th would be easier to remember[1].

~Niels

[1] I think the 5th of November is also "Gunpowder day" and also happens
to have a good simple mnemonic/rime:

"""
Remember, remember
the fifth of November
"""

(Not sure of the origins of the rime; I remember it being used in "V
from Vendetta" though.)



-- 
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/525aeac5.9060...@thykier.net

Re: Bits from the Release Team (Jessie freeze info)

[Niels Thykier]

On 2013-10-13 19:41, Bernd Zeimetz wrote:
> Hi,
> 
>> We are happy to announce that we will freeze Jessie at 23:59 UTC on the 5th
>> of November 2014.
> 
> thanks for annoucing that early and for your work!
> 

You are welcome.  :)

>> [...] * Proactive automated removals 3 months into the freeze. - Note that
>> bug-free packages will be removed if they (build-)depend on a RC-buggy,
>> non-key package.
> 
> Could we get a warning about such removals before they are scheduled? Like at
> least one week before? Having an eye on all packages all my packages
> build-depend is something which would be great to avoid ;)
> 

We could "just" finish the finish the freeze within 3 months and not
have this problem at all! XD

Honestly, I am hoping we can have such a list of packages be found in an
automatically.  At the current time, about 3k of all source packages
builds at least one key package vs. a total of 20k-21k source packages
(in sid).  A quick estimate suggests that we got over 80% source
packages that could be candidates for such removals.
  If I have to find those manually, I will probably end up being pretty
sad (and unable to do it on a regular basis - which would somewhat
defeat the purpose of this idea).


>> [...]
> 
>> - Native packages are at a disadvantage here, since all uploads of native
>> packages are considered a new "upstream" version.
> 
> So whats the "fix" for that? Migrating native packages to non-native ones does
> not always make sense.
> 

The quick fix is to not do these "carte blanche"-unblocks at all, which
is the status-quo/current plan.  Obviously, if the upload of a native
package fits the freeze policy, it can still receive a manual unblock.
  But honestly, I would prefer if we didn't need to resolve this gray
area at all.  If people are trying to rely on "carte blanche"-unblocks,
they might be optimising for the "wrong thing".  Having your packages
ready and *in testing* before November is really a much simplier and
easier for all parties involved.  Bonus if they are 100% bug free too.

On a related note: I would recommend people to get accustomised to
interpreting the excuses from Britney[1] and keeping an eye out for
"Valid candidate"-packages that are not migrating despite being in that
state for a couple of days.  Even if we were to do "carte
blanche"-unblocks, your package must still be able to migrate as-is,
which apparently caught many people by surprise during the Wheezy cycle.
  This is actually another argument for not doing these "carte
blanche"-unblocks.  We had quite some difficulty in conveying our
intention behind them.  People seemed to have quite a different
understanding of how they were "supposed to work".

Side note: Should you be fed up with Britney's (un)helpful exucses-page,
you are more than welcome to get in touch with us and to help us write
patches to classify the problems better.

> 
>> [...] - It should also go without saying that embedding a new upstream
>> release in a patch just to get a such "carte blanche" exception is also
>> considered abuse.
> 
> What about bugfix point-releases from upstream, like postgres and other sane
> upstreams do it?
> 
> 
> thanks & cheers,
> 
> Bernd
> 
> 

If you are doing a new point release, you ought to bump the upstream
version of your package.  As soon as you do that, it would no longer be
applicable for a "carte blanche" unblock.
  The note referenced above is about embedding all the upstream changes
in a "Debian patch" and only bumping the Debian revision (while keeping
the "upstream version" unchanged).  Basically, it is a "don't game the
system"-rule (like the "don't abuse urgency"-rule).

~Niels

[1]  They are admittedly not always very helpful to
"non-Britney-developers".  Basically, people tend to get confused by
"out of date"-binaries and side-effects caused by having "out of
date"-binaries.

See also:
http://nthykier.wordpress.com/2013/07/14/britney-excuses-ood/

"""
The tricky part of an “out of date”-excuse is that Britney simply
identifies a symptom and not a cause.
"""

Side-effects of "out of date"-binaries may include "RC bugs fixed in sid
is not considered fixed by Britney" and "package not migrating to testing".


-- 
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/525af8ba.30...@thykier.net

Re: Bits from the Release Team (Jessie freeze info)

[Niels Thykier]

On 2013-10-13 17:01, Niels Thykier wrote:
> 
> Freeze date and Freeze Policy for Jessie
> 
> 
> We are happy to announce that we will freeze Jessie at 23:59 UTC on
> the 5th of November 2014.
> 
> To avoid any confusion around exactly how we will freeze, we have
> prepared a draft of the Jessie Freeze Policy in advance
> [FREEZE_POLICY].
> 
> [...]
> 
> As noted we are dealing with a draft, so there may be changes to the
> actual freeze policy.  Should we change the policy in a substantial
> way, this will be included in subsequent "bits".
> 
> [...]
> 
> Niels, on behalf of the Debian Release Team.
> 
> [FREEZE_POLICY]
> http://release.debian.org/jessie/freeze_policy.html
> 
> [...]

Hi,

I have gotten several (private) follow-ups asking whether 2014 is a typo
or not.  Obviously, it did not help that there was a typo in the freeze
policy listing 2013 in some places (they should now all say 2014).  So
to clarify:

"""
  We will freeze the 5th November 2014, which is about thirteen months
  from now (i.e. next year).
"""

~Niels


-- 
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/525b1038.1080...@thykier.net

Re: First autoremovals happen in about 8 days

[Niels Thykier]

On 2013-10-15 15:35, Andreas Tille wrote:
> Hi Niels,
> 
> [sorry for the late reply I was on vac]
> 

Hi,

No worries.

> On Sun, Oct 06, 2013 at 09:52:17AM +0200, Niels Thykier wrote:
>>
>> Andreas Tille 
>>gdpc: bugs 713652, flagged for removal in 8.3 days
> 
> Fixed.
> 

Thank you,

>>gwyddion: bugs 713565, flagged for removal in 8.3 days
> 
> Hmmm, that's really strange.  The bug report was closed
> 
>Sat, 29 Jun 2013 13:07:42 +0200
> 
> Seems something is wrong with the script.
> 

I am more inclined to believe that you experienced one of the quirks of
the Debian BTS.  According to the BTS, it is:

"""
Fixed in version src:gwyddion/2.28-2
"""

In the bottom of the bug log you will find:

"""
No longer marked as found in versions gwyddion/2.28-2
"""

meaning that the bug was (or, rather, used to be) marked as "fixed" in
the same version as it was "found".  The BTS handles this by *silently
ignoring the fixed version* and thus concluding the bug is still in
2.28-2.  It then hands that off to Britney and the auto-removal script,
which will consider 2.28-2 as buggy as well.

>>praat: bugs 713597, flagged for removal in 8.3 days
> 
> We'll care about this in Debian Med team.
> 

\o/

>>r-other-mott-happy: bugs 709190,713284, flagged for removal in 8.3 days
> 
> Besides the fact that this package should actually removed from testing
> (perhaps even from Debian - the actual Uploader in our team should take
> action about this) I noticed that something seems to be wrong in
> rendering the BTS page.  While the first bug (#709190) is mentioned
> the second one (#713284) is missing on the BTS page:
> 
>http://bugs.debian.org/cgi-bin/pkgreport.cgi?src=r-other-mott-happy
> 
> Any explanation for this?
> 

Well, they are merged into each other and thus the BTS decided only to
show one of them in the bug page.  However, both bugs appear when you
reference then directly via [1] and [2].

> Kind regards
> 
>   Andreas.
> 


~Niels

[1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=713284

[2] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=709190



-- 
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/525d48df.3060...@thykier.net

Re: Bits from the Release Team (Jessie freeze info)

[Niels Thykier]

On 2013-10-19 16:38, Jeremiah C. Foster wrote:
> Hello,
> 
> On Sun, Oct 13, 2013 at 05:01:31PM +0200, Niels Thykier wrote:
> 
> [snip freeze policy]
>  

Hi,

I s/-arm/-ports/'ed the CC, since I figured the rest of the porters
would find the answer equally interesting.

>> Results of porter roll-call
>> ===
>>
>> [...]
>>
>> That said, we would like to encourage porters behind all ports to
>> ensure that the toolchain is up to date and working.  We are aware of
>> at least gcc on mips having its test suite disabled[GCC].  Other ports
>> may suffer from similar issues and we hope to have those resolved
>> sooner rather than later.  We are currently waiting for the gcc
>> maintainers to compile a list of such issues.
> 
> So I can extrapolate from this that ensuring that the toolchain is up
> to date and working is a key activity of a porter.

Yes; build-essential being broken is obviously a problem.  But also
having the same default compiler on all architectures is also desired.

> If my assumption is
> correct, is there a complete definition of the "toolchain" as we see
> it in Debian that a porter might reasonably be expected to use to do
> thier porting?
> 

I do not have an complete list of packages, although it will definitely
include build-essential.  My intuition is that "toolchain" should
include any compiler used by packages on that architecture[1] (e.g. if
the arch has built haskell packages, it should have a working haskell
compiler as well).  But as said, that is my personally view and not an
official statement.

> In addition, I wonder if there is a way to report the status of the
> toolchain and what sort of expectations are there around "up to date"?

I would love for us to have an automated system to give us a
"weather-report" on the toolchain for each architecture.  It would be
nice both for us to see how ports are doing and for porters to spot and
fix problems early.
  As for up-to-date, I don't have a complete answer here.  I seem to
remember the GCC maintainers being frustrated at having to maintain
gcc-4.6 (it is apparently still default for some architectures) despite
gcc-4.8 being the latest stable release.

> Is it expected to build Debian toolchain nightly and run a specific
> test suite? Is the expectation that one uses pbuilder and builds a set
> of packages?

What we got in the policy so far[2]:

"""
Installer: The architecture must have a working,tested installer.
[...]

Archive coverage: The architecture needs to have successfully compiled
the current version of the overwhelming part of the archive [...]
"""

Which implies "a set of packages" being "the current version of the
overwhelming part of the archive" plus all of d-i.  However, that is not
something you "just build", so having a smaller set as a basic test
would probably be way more useful.  I am not aware of such a "basic test
set", so feel free to propose one.

I like the "toolchain nightly" thing as well. I don't think it is
"required", but it sounds like the kind of thing that would help people
spot issues sooner rather than later!

> Perhaps this is outlined on the wiki somewhere and if not
> perhaps it ought to be?
> 
> Regards,
> 
> Jeremiah
> 
> 

Having documentation on it would definitely be a good thing.  For actual
requirements, we should add them to the policy[2], but having a
wiki-page of "recommended porter practises/tests" would probably be a
nice addition too.

~Niels

[1] My rationale for this is that we would like to be able to
rebuild/reproduce builds, which would require a working compiler.

[2] http://release.debian.org/jessie/arch_policy.html



-- 
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/52654b6d.9020...@thykier.net

Re: Bits from the Release Team (Jessie freeze info)

[Niels Thykier]

On 2013-10-29 16:05, Ian Jackson wrote:
> Niels Thykier writes ("Bits from the Release Team (Jessie freeze info)"):
>> Results of porter roll-call
>> ===
> ...
>> Summary table:
>> Arch   || DDs || NMs/DMs || Other || Total
>> - ---++-++-++---++--
>> armel  ||  5  ||   0 || 2 ||7
>> armhf  ||  6  ||   1 || 2 ||9
>> hurd-i386  ||  5  ||   0 || 3 ||8
>> ia64   || *0* ||   0 || 3 ||3
>> kfreebsd-amd64 ||  5  ||   0 || 2 ||6
>> kfreebsd-i386  ||  5  ||   0 || 2 ||6
>> mips   ||  2  ||   0 || 1 ||3
>> mipsel ||  2  ||   0 || 1 ||3
>> powerpc[1] || (1) ||   0 || 2 ||   2.5?
>> s390x  ||  1  ||   0 || 1 ||2
>> sparc  ||  1  ||   0 || 0 ||1
> ...
>> Based on the number of porters, we are considering changing the
>> current requirements of "5 DDs" to better reflect the reality of the
>> situation.  We will follow up in a future bits on the changes.
> 
> Thanks.
> 

You are welcome. :)

> I think it is disappointing to find that we may be dropping
> architectures where a significant amount of effort is available,
> simply because the volunteers don't have enough status - specifically,
> because of a lack of DDs.
> 

As mentioned we are debating whether the "5 DDs" requirement still makes
sense.  Would you say that we should abolish the requirement for DD
porters completely?  I.e. Even if there are no (soon to be) DDs, we
should consider the porter requirements fulfilled as long as they are
enough "active porters" behind the port[0]?

> I'm keen that Debian should continue to support a wide range of
> architectures.  Would it help if I, as a DD, volunteered to sponsor
> porter uploads for any architecture ?  That is I guess I'm
> volunteering to become a new kind of person - a "non-port-specific
> porter sponsor".
> 

I suppose that could help ports without a DD if we allowed such to be in
testing.  However, it is my understanding that our main issue with ports
often is that they are not actively maintained (or appears to lack
active maintenance).
  As an example I remember having received several complains from e.g.
the GCC maintainers in regards to the state of gcc on various ports[1].
 Here I would suspect a patch would be sufficient without needing to
actually NMU gcc to get the fix in.
  There are also stuff like the port concerns from DSA that attention.

> Obviously I will review the debdiff etc.  I'm an experienced C
> programmer with some background in C language lawyering and
> portability stuff, so I should usually be able to do a decent review
> of a patch even on an unfamiliar architecture.
> 
> In fact, regardless of what the release team decide for the policy, I
> would be happy to sponsor porter uploads.  Please just email me.
> 
> Ian.
> 
> 

:)

~Niels

[0] Leaving the definition of "active porter" vaguely defined for now.

[1] Obviously, I haven't been keeping track of them so I had to ask for
a reminder.

https://lists.debian.org/debian-release/2013/10/msg00710.html



-- 
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/526fdfe3.7060...@thykier.net

Re: [Question] lin-guider: block ITP 727532 by RFS 727618

[Niels Thykier]

On 2013-10-30 07:19, James Lukash wrote:
> Hello all. I received a message about my ITP bug:
> ===
>> block 727532 by 727618
> Bug #727532 [wnpp] ITP: lin-guider -- Astronomical autoguiding program
> 727532 was not blocked by any bugs.
> 727532 was not blocking any bugs.
> Added blocking bug(s) of 727532: 727618
>> stop
> Stopping processing here.
> ===
> What does it mean? What bugs? How to get detail information about my bugs?
> How to fix it?
> It's my first package. Thanks for your answers.
> 
> Regards, James Lukash.
> 

Hi,

I took the liberty of CC'ing you since I wasn't you were subscribed.
Please keep in mind that many (but not all) Debian mailing lists assumes
you are subscribed unless you explicit state otherwise.

For future reference, you are probably more likely to get help on
debian-ment...@lists.debian.org for questions about packaging and for
help with being a new packager.


In regards to your actual question.  You can look up any Debian bug by
its ID via:

   http://bugs.debian.org/

e.g.

  http://bugs.debian.org/727618

In the particular case, you will see that #727618 is your RFS bug.  In
the top of the bug should also see the "Blocking fix for" (or "Fix
blocked by" if you access #727532) that links to the other bug (as long
as it is open).

~Niels



-- 
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/5270ac0c.4090...@thykier.net

Potential issues for most ports (Was: Re: Bits from the Release Team (Jessie freeze info))

[Niels Thykier]

On 2013-10-29 17:48, Ian Jackson wrote:
> Niels Thykier writes ("Re: Bits from the Release Team (Jessie freeze info)"):
>> [...]
>> As mentioned we are debating whether the "5 DDs" requirement still makes
>> sense.  Would you say that we should abolish the requirement for DD
>> porters completely?  I.e. Even if there are no (soon to be) DDs, we
>> should consider the porter requirements fulfilled as long as they are
>> enough "active porters" behind the port[0]?
> 
> I don't have a good feel for the answer to that question.  
> 
> It's just that if it is the case that a problem with ports is the lack
> of specifically DDs, rather than porter effort in general, then
> sponsorship is an obvious way to solve that problem.
> 
> If you feel that that's not really the main problem then a criterion
> which counts porters of any status would be better.
> 

I suppose a "sponsor-only" DD could be sufficient, provided that the
sponsor knows the porters well enough to be willing to sign off on e.g.
access to porter boxes.  I guess the sponsor would also need to dedicate
time to mentor (new?) porters on workflows and on quicks like when is a
FTBFS RC and when it isn't etc.

> (Mind you, I have my doubts about a process which counts people
> promising to do work - it sets up some rather unfortunate incentives.
> I guess it's easier to judge and more prospective than a process which
> attempts to gauge whether the work has been done "well enough".)
> 
> [...]
> 
> Thanks,
> Ian.
> 
> 

Ah, you are not the first to question this process.  Obviously, we
intend to keep people up on their promise by "actively maintaining their
port".  Sadly, we do not have a clear definition of "actively maintained
ports" and I doubt we will have it any time soon either.
  But porters can start by working on the concerns from DSA (if they
haven't already done so).  Ports having gcc-4.6 as default compiler
might also consider improving in that area[1].

Then there are more concrete things like ruby's test suite seg. faulting
on ia64 (#593141), ld seg. faulting with --as-needed on ia64
(#718047[2]), a lot of ruby packages being stuck on kfreebsd-any due to
ruby2.0 FTBFS (#726095[3]).  Personally, I would also expect that
key-packages work on all ports (on which they are built) in general[4].

All of the (non-mild) DSA concerns are already something we will
officially hold against the ports.  Most of the other issues listed
above are not official concerns.  However, I would not be surprised if
most of them became official issues eventually.


Until we have a clear definition of "actively maintained ports", I would
recommend porters to err on the side of being verbose over being silent.
 As an example, lack of visible reply to mails like [5] makes it seem
like nobody is home.
  Mind you, I am not saying porters have the responsibility to fix every
problem forwarded to their port list.  I am also aware that sometimes
issues/mail "disappear" in the depths of people inbox - heck it happens
to me as well.
  Come to think of it; maybe we should have a BTS page for each of the
ports (e.g. a pseudo package in the BTS).  That way it would at least be
easier for all people to find outstanding issues for the port[6].  It
would also give us the possiblity to trivial declare a problem RC (or
not) for ports.  (Plus, then I won't have to update some random file on
release.d.o for every new issue :P)

Anyhow, I hope to be able to give a more "official" statement in the
near future.

~Niels

[1] Nothing official yet, but gcc-4.6 (and earlier) /might/ not be
acceptable as a default for Jessie.

[2] Apparently it is controversial whether that bug should be RC, but it
definitely looks like that kind of thing that will cause issues for ia64
later.

[3] That one got a patch, but it might be worth it to put some pressure
on the maintainer or even doing a NMU.

[4] A rule of thumb could be something like "your port should probably
not be listed here in the long run:

http://udd.debian.org/bugs.cgi?release=jessie_and_sid&merged=ign&keypackages=only&fnewerval=7&flastmodval=7&rc=1&sortby=id&sorto=asc
"

[5] https://lists.debian.org/debian-mips/2013/08/msg5.html

Btw, this is not intended to single out mips.

[6] I know that people have been usertags for issues that affect the
port, but it is not clear to me that all those usertags bugged is
something we expect porters to fix.  Rather it seems more like porters
tagging the FTBFS bugs they file.



-- 
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/52762b6a.5060...@thykier.net

Re: Potential issues for most ports

[Niels Thykier]

On 2013-11-03 15:49, Thorsten Glaser wrote:
> Niels Thykier dixit:
> 
>> [...]
>> Until we have a clear definition of "actively maintained ports", I would
>> recommend porters to err on the side of being verbose over being silent.
> 
> I’ve held off on the m68k side because I think the role call was only
> for architectures in the main archive, right?
> 

Yes, we are only talking about architectures in the main architecture.

>> [1] Nothing official yet, but gcc-4.6 (and earlier) /might/ not be
>> acceptable as a default for Jessie.
> 
> Didn't Doko say he’d want 4.8? We (on the m68k side) are putting
> effort into that one, since 4.7 appears to only be used by eglibc
> right now. And 4.6 for GNAT, but gnat-4.8 is new, and the ICE may
> be fixed as there’s active upstream on the GCC/m68k side.
> 
> bye,
> //mirabilos
> 

I am not entirely up to speed on what he wants; I am still waiting for
him to get back to me (see [1]).

~Niels

[1] https://lists.debian.org/debian-release/2013/10/msg00710.html



-- 
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/527671af.7050...@thykier.net

Re: Potential issues for most ports

[Niels Thykier]

On 2013-11-03 16:54, Niels Thykier wrote:
> On 2013-11-03 15:49, Thorsten Glaser wrote:
>> > Niels Thykier dixit:
>> > 
>>> >> [...]
>>> >> Until we have a clear definition of "actively maintained ports", I would
>>> >> recommend porters to err on the side of being verbose over being silent.
>> > 
>> > I’ve held off on the m68k side because I think the role call was only
>> > for architectures in the main archive, right?
>> > 
> Yes, we are only talking about architectures in the main architecture.
> 

s/main arcihtecture/main archive/;

~Niels



-- 
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/527674bd.2070...@thykier.net

Re: Potential issues for most ports (Was: Re: Bits from the Release Team (Jessie freeze info))

[Niels Thykier]

On 2013-11-03 16:03, Steven Chamberlain wrote:
> On 03/11/13 10:54, Niels Thykier wrote:
>> Come to think of it; maybe we should have a BTS page for each of the
>> ports (e.g. a pseudo package in the BTS).
> 
> We've had this on kfreebsd, due it to having been a release goal:
> 
> http://udd.debian.org/bugs.cgi?release=jessie_or_sid&merged=ign&fnewerval=7&kfreebsd=1&sortby=severity&sorto=desc&cseverity=1&ctags=1
> 


Actually, I meant a "real" BTS page (e.g. like [1]) rather than "just" a
list of tagged bugs.  The list of tagged bugs definitely have it uses,
but it does not give me an overview of which bugs should be fixed by the
maintainer of the given package and which the porters should fix.

> It uses usertags, but someone has to set those.  Porters usually set
> them on bugs they file;  but quite often "FTBFS on kfreebsd" bugs are
> filed without being tagged or Cc'd to our list, so someone has to
> periodically look for and tag things.
> 
> Regards,
> 

In this regard; I am guilty of filing some those bugs without tagging
them.  Honestly, adding the tags get a bit in the way right now.  If a
package FTBFS on 4 architectures, I have to dig up 3-4 different
usertags (with different "user") and associate it with the bug.
  Do we have a tool you can give a source package, a version plus a list
of architectures and it will generate a bug with the right tags?  I
think that would help a lot for me.

~Niels

[1] http://bugs.debian.org/release.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/52789fdb.2000...@thykier.net

Re: Potential issues for most ports (Was: Re: Bits from the Release Team (Jessie freeze info))

[Niels Thykier]

On 2013-11-03 23:04, Steve Langasek wrote:
> On Sun, Nov 03, 2013 at 11:54:34AM +0100, Niels Thykier wrote:
>> [...]
> 
>> I suppose a "sponsor-only" DD could be sufficient, provided that the
>> sponsor knows the porters well enough to be willing to sign off on e.g.
>> access to porter boxes.  I guess the sponsor would also need to dedicate
>> time to mentor (new?) porters on workflows and on quicks like when is a
>> FTBFS RC and when it isn't etc.
> 
> Why would the sponsor need to be involved in getting the porters access to
> porter boxes?  Porter boxes exist so that DDs *not* involved in a port have
> access to a machine of the architecture and can keep their packages working.
> I've never heard of a porter who didn't have access to their own box for
> porting work.
> 

I will not rule out that it was a poor choice of example on my part for
ia64 (and maybe powerpc), which is(/are) the concrete port(s) we would
be talking in this case.
  That said, it is my understanding that "one does not simply own an
s390(x)"[1].  Nor would I be concerned to have arm porters that worked
on all 3 arm ports while possessing hardware only for a (non-empty)
subset of those architectures.

~Niels

[1] I certainly wouldn't have space for something like this:

 http://en.wikipedia.org/wiki/File:Z800_2066_JKU.jpeg

(and much less the money.  Yeah I know that is technically not an s390,
but as I understand it, an s390 should be "around that size")



-- 
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/5278a3e1.30...@thykier.net

Re: release goal proposal: enable hardening build flags

[Niels Thykier]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 2011-09-14 00:38, Kees Cook wrote:
> Hi,
> 
> I would like to propose a release goal of enabling hardening build flags[1]
> for all C/C++ packages in the archive[2]. For Wheezy, specific sub-goals are
> being chosen.
> 
> The default flags are almost settled[3], additional subgoals may come
> up[4], and more work is needed to identify the specific packages involved
> in the subgoals[5], but I'd like to get the ball rolling on this as a
> release goal.
> 
> Thanks,
> 
> -Kees
> 
> [1] http://wiki.debian.org/Hardening
> 
> [2] http://wiki.debian.org/ReleaseGoals/Hardening
> 
> [3] http://lists.debian.org/debian-dpkg/2011/09/msg00025.html
> 
> [4] http://lists.debian.org/debian-devel/2011/09/msg00071.html
> 
> [5] 
> http://anonscm.debian.org/viewvc/secure-testing/hardening/subgoal-important.txt?view=log
> 
> http://anonscm.debian.org/viewvc/secure-testing/hardening/subgoal-dsa.txt?view=log
> 

Hi,

I am pleased to say this release goal has been approved for Wheezy.
Please remember to use the right usertag[1].

~Niels

[1] http://lists.debian.org/debian-release/2011/09/msg00472.html

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

iQIcBAEBCAAGBQJOnoUHAAoJEAVLu599gGRCc8QP/jbx1q9QusXqqPTD0qgwJZf/
zwdVm0ChOT5DrnkqX+cX79eRvdhLvFWEedGWTzQ+xqWChv7RZiGP6JgmHzu4Us9Z
gkXIgcrINoOQYklSq7BVh3uR21rw9TtMUWV9nXwgraMi7z2m+LUKmzzYEjChSE4U
hP/0yXfg0O2h41Kj6CfM3l9pGOSY0DEk7YYC2BKn0jX/QBiSCqZMjqQp9S/SXYKm
JxITONNLZKAv0R0AgR6BSv00VCtEyakuobiU9tZjjRZfxtAA3eqCimuR4oNZeFGP
7SsfSZQ5nCgQeGa0mR3hWf0WjMFPmwMn/+8Nq7Yevy517L4faRy7BdUnFNkSldmp
ZmmHIdxnlz/6wp5Bn/tqrIBM+Ylflqgy0RpPayr0EQhY9a9+vD0ZP1HjjMP3Gl9n
RAQIo/pHjupdW88Ru4ejEqBHHXCGUqNhEf9fujXKEmwQvggzZ5FEqGqNEnT70hSF
8lKqqAJDp4Ng9BkqKFdL0Mo7Bx0gZntfAycsRuin9s5LnG9G/6ajFAskNgqp5Smn
Cd4bPWNHJ0eESCuNCk7wudyJV55A6Y1yexNF2PkL30LobYYNd42asnyhixR690rK
NBo7NKqJ55seimdejadivsv0dwPOEmp6nJqHxIYWL8gLu2hw0+hRyilYJC1OYYTV
16mJIKLS2HzSKvkxJ72z
=qhHy
-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/4e9e8508.1030...@thykier.net

Re: Debian unstable/expirental missing some bnx2 firmwares

[Niels Thykier]

On 2011-10-30 10:26, Sébastien Riccio wrote:
> Hi,
> 
> I don't know much where to write about this, but i'll try here. Sorry if
> it's the wrong place!
> 
> I updated a squeeze box to unstable/experimental in order to try out the
> xapi (project kronos) port on Debian, but got into this on my test box:
> 
> update-initramfs: Generating /boot/initrd.img-3.0.0-2-686-pae
> W: Possible missing firmware /lib/firmware/bnx2x/bnx2x-e2-6.2.9.0.fw for
> module bnx2x
> W: Possible missing firmware /lib/firmware/bnx2x/bnx2x-e1h-6.2.9.0.fw
> for module bnx2x
> W: Possible missing firmware /lib/firmware/bnx2x/bnx2x-e1-6.2.9.0.fw for
> module bnx2x
> 
> When i rebooted the box, the bnx2 drivers says it can't load the
> firmware for my nic.
> 
> It seems that package firmware-bnx2 is missing some firmwares used for
> the 3.0.0-2-686-pae kernel.
> I know it's experimental, but is there a workaround ?
> 
> Thanks a lot for your help.
> 
> Kind regards,
> Sébastien
> 
> 

Hi,

Have you enabled non-free? There is a "firmware-bnx2x" in non-free,
which is probably what you are looking for.

~Niels



-- 
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/4ead1c09.9010...@thykier.net

Orphaning lprfax

[Niels Thykier]

severity 645793 normal
reassign 645793 wnpp
retitle 645793 O: lprfax - Utility to allow printing to a fax modem
thanks


Hi,

I am orphaning lprfax[1] on behalf of Camm Maguire (see #645793).

Due to its RC bugs and its very low popcon I intend to request the
removal of this package in about 14 days, if no one picks it up.

~Niels

[1]
Package: lprfax
Version: 0.6-28
Installed-Size: 204
Maintainer: Camm Maguire 
Architecture: i386
Depends: libc6 (>= 2.0), netpbm, magicfilter, ghostscript, transfig,
libjpeg-progs, texlive-latex-base, poppler-utils
Pre-Depends: lprng (>= 3.6.12), debianutils (>= 1.6), mgetty-fax
Suggests: samba, smbclient
Description: Utility to allow printing to a fax modem
 lprfax provides a set of scripts and programs to control network
 fax spooling through the LPRng print system.  The goal is to enable
 transparent faxing in any application able to print, via
 'lpr -Pfax -J'.
 Features:
  * integration with mgetty/sendfax system and configuration files
  * load balancing among multiple fax modems
  * remote queue/log inspection and control
  * Customizable cover page generation via banner-page filters
  * Customizable name/fax number lookup from job specification
  * automated fax retries via lprng hold/release mechanism
Tag: hardware::modem, qa::low-popcon, role::program, scope::utility,
works-with::fax
Section: net
Priority: extra
Filename: pool/main/l/lprfax/lprfax_0.6-28_i386.deb
Size: 27176
MD5sum: e92eb21263ead68bbee351ddf89b5b8f
SHA1: aebf1d979b0bb99c98a784f8fb2262f6b99717c9
SHA256: 89f70a1c124bdba1f850e78710c46c187004372031ef23c54591cc6c1d7a9f6e


-- 
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/4eb539e1.3040...@thykier.net

Release goal proposal: Archive-wide build-arch and build-indep support

[Niels Thykier]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256


Hi,

I would like to propose the goal of getting archive-wide support for
the optional debian/rules targets "build-arch" and "build-indep".
The intention is to finally solve issues like #619284 and the goal
is related to #629385.

According to Lintian, currently 5542 packages are missing at least
one of these optional targets.  At the current rate these are fixed
it will take over 2 years to get them all done and unfortunately the
rate appears to be slowing dropping[1].

Jakub Wilk did an analysis earlier this year, which suggests we can
reduce the problem size considerably by looking only at source
packages that builds both "arch:all" and "non arch:all" binaries[2].
I have filed #647227 against Lintian asking for a separate tag to
identify these packages.

To keep it attainable, the goal for Wheezy is to fix the subset of
packages that would need to differentiate "build" and
"build-arch"/"build-indep".  Once we have the data available, we
will put up a dd-list for the reduced set.


If you would like to help:
 * Fix you(r team)'s packages (see [3])
 * Sign up as an volunteer.
   - There are up 126 QA uploads waiting to be done. :)
   - There will probably also be some NMUs.
 * If filing bugs for this, please use:
   * User: debian...@lists.debian.org
   * Usertags: build-arch-target 

The release goal wiki page is at [4] and the current advocates are
Jakub Wilk, Bernhard R. Link and myself.

Thanks for considering.
~Niels


[1] This data is available on lintian.d.o as:

/srv/lintian.debian.org/history/tags/debian-rules-missing-recommended-target.dat
 
format is:
   


[2] http://lists.debian.org/debian-policy/2011/06/msg00018.html


[3] This dd-list is the full set of packages (the reduced set is not
available at the moment).

http://people.debian.org/~nthykier/rg-build-arch-target/dd-list


[4] https://wiki.debian.org/ReleaseGoals/BuildArchTarget

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

iQIcBAEBCAAGBQJOtZrYAAoJEAVLu599gGRCekUP/296/iJsyugdBZ3bgk/MsF9E
z6lIFve0KdkH8+ze8tigIW7fXtXE2Zep3/Yr3AxUfrJ7gPmKJEPUpDxD+k8bxCs3
46MdgGAGydwmYz2sYdEp7T+HCeZwVqEcW9beWSlXj5ni9qxZSfcev7/f0mQL7z3v
pyGzRZE8EloaDpflFCi9Hclot07pVoO8VHNMJq2mZpw1Sx2mAEAeFisq9UQgUTcH
C3MNo541TF8v8WiyvH5UA+LG6uG+MrN/1mB7MGYzYWB4byx3SelcilSdgDmbWasY
T0MZ4zt+1kEas7GwO1gMM4w6ezsr/PLN+INh56i1SgiKOvucza5OK2MA1uyybnMB
pp6MQerLJYbPkhMEkPDqTqYNDKUFwLmaV7hXcUNFZYaAh8Qcrz1wb9r9+xeI8A2b
MY+jiiQABBH670IAD70EhaVAHa9YzjcZLqXN1NEwBLCpiipfj5QeYdhZt4Ssu45Z
ofbw50sA3qjRupJA50WhWtN605w3SYmxaWLGdsyRN8cA+UkJJGsoxr1YQoDuCA0Y
KY/dmz73mufWmNdj2MAPEWvOszCEympYbZ0/ks5b0vgB3xK1NJKj2IHLO7RtrrC3
T6LMc0/EuZnGFUS8yW01G94rLJjZFylHaRpHbXELR5goREZMkjS/4QPOjVcIF0zP
7VByuLIO4kQtFePvesbm
=s/mk
-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/2005202219.be91c2000a...@thykier.net

Re: Release goal proposal: Archive-wide build-arch and build-indep support

[Niels Thykier]

On 2011-11-05 21:22, Niels Thykier wrote:
> 
> Hi,
> 
> I would like to propose the goal of getting archive-wide support for
> the optional debian/rules targets "build-arch" and "build-indep".
> The intention is to finally solve issues like #619284 and the goal
> is related to #629385.
> 
> [...]
>
> To keep it attainable, the goal for Wheezy is to fix the subset of
> packages that would need to differentiate "build" and
> "build-arch"/"build-indep".  Once we have the data available, we
> will put up a dd-list for the reduced set.
> 
> [...]

The reduced set is available thanks to some UDD queries.  We are looking
at ~500 packages (see attached dd-list if some of your packages are there).

The data is also available from[1], where you can also see the queries I
used to generate this set (see reduced-set.py).


Thanks for considering,
~Niels

[1] http://people.debian.org/~nthykier/rg-build-arch-target/


"Adam C. Powell
   hypre (U)
   illuminator (U)
   opencascade (U)
   spooles (U)

Nicolas Valcárcel Scerpella (Canonical) 
   augeas

Daniel Leidert (dale) 
   bluefish
   gdis (U)
   gnupg (U)

Davide Puricelli (evo) 
   xchat

Felipe Augusto van de Wiel (faw) 
   lifelines

Laszlo Boszormenyi (GCS) 
   libcrypto++

Adam Cécile (Le_Vert) 
   libtunepimp
   museek+

Masayuki Hatta (mhatta) 
   aiksaurus
   libwpd (U)
   ng
   zipios++

Stefan Hornburg (Racke) 
   courier
   interchange
   pure-ftpd

J.H.M. Dassen (Ray) 
   libgsf
   lout

Vincent Duvert (VinDuv) 
   slimevolley (U)

Michael Ablassmeier 
   zabbix (U)

Clint Adams 
   freeciv (U)
   u-boot
   zsh (U)

Clint Adams 
   micropolis-activity (U)

Aide Maintainers 
   aide

Moray Allan 
   libgpewidget (U)
   libxsettings-client (U)

Russ Allbery 
   krb5 (U)

Thorsten Alteholz 
   mpb

Emile Anclin 
   xmldiff (U)

Micah Anderson 
   augeas (U)

Domenico Andreoli 
   boost1.46 (U)

Osamu Aoki 
   scim-tables (U)

Paulo Assis 
   libwebcam

Anibal Avelar 
   centerim

Khalid Aziz 
   openhpi (U)

Michael Banck 
   gridengine (U)
   libsyncml

Andreas Barth 
   mgetty

Mirco Bauer 
   mono (U)

Axel Beckert 
   amora-server
   zsh (U)

Dave Beckett 
   cairo

Dominique Belhachemi 
   vtk (U)

Luciano Bello 
   imagemagick (U)

Philipp Benner 
   cunit
   transmission (U)

Vincent Bernat 
   libsmi

Olly Betts 
   wxwidgets2.6 (U)

Sylvain Beucler 
   freedink (U)

Julien BLACHE 
   xsane

Bastian Blank 
   ibm-3270
   parted (U)
   redhat-cluster (U)

Eduard Bloch 
   liquidwar (U)

Phil Blundell 
   libgpewidget (U)
   libxsettings-client (U)

Wolfgang Borgert 
   dia (U)

A. Maitland Bottoms 
   dime
   icomlib
   vtk

Gonéri Le Bouder 
   kraptor (U)
   lincity-ng (U)
   monsterz (U)
   netpanzer (U)
   ri-li (U)
   stormbaancoureur (U)
   xtux (U)

Nicolas Boulenguez 
   gnat-gps (U)

Joachim Breitner 
   ghc (U)
   pidgin-blinklight
   xaralx

Ludovic Brenta 
   gnat-gps
   libaws
   polyorb (U)

Rogério Brito 
   dvdisaster (U)

Frank B. Brokken 
   yodl

Paul Brossier 
   freebirth

Rob Browning 
   guile-1.6

Cyril Brulebois 
   compiz (U)
   liblouis (U)

Cyril Brulebois 
   lincity-ng (U)
   ri-li (U)

Jan-Michael Brummer 
   isdnutils (U)

Floris Bruynooghe 
   omniorb-dfsg (U)
   python-omniorb (U)

Martin Buck 
   apcalc

Reto Buerki 
   polyorb

Ansgar Burchardt 
   ketm (U)

Krzysztof Burghardt 
   tilp2

Daniel Burrows 
   aptitude
   criticalmass
   libsigc++-2.0

Michael Casadevall 
   python-qt3 (U)
   python-qt4 (U)

Vagrant Cascadian 
   ldm (U)

Ondrej Certik 
   abinit (U)

Juan Cespedes 
   linux86

Pierre Chifflier 
   nufw

Nanakos Chrysostomos 
   xlog

Patryk Cisek 
   qnapi

Adam Conrad 
   util-linux (U)

Kees Cook 
   apparmor

Leo Costela 
   gnokii
   transmission

Philippe Coval 
   tuxguitar
   whitedune (U)

Luis Rodrigo Gallardo Cruz 
   librep
   liferea
   rep-gtk
   sawfish

Adrien Cunin 
   libdjconsole

Tim Cutts 
   am-utils

Artur R. Czechowski 
   libqglviewer

Marco d'Itri 
   ifmail
   ppp

George Danchev 
   yodl (U)

Vincent Danjean 
   idzebra

LI Daobing 
   liblunar
   scim-python (U)
   zinnia (U)

LI Daobing 
   scim-tables (U)

Debian Accessibility Team 
   brltty
   liblouis
   liblouisxml

Debian Acpi Team 
   acpi-support

Debian allegro packages maintainers 

   overgod
   rafkill
   wing

Debian aMule Team 
   amule

Debian Boost Team 
   boost1.46

Debian Citadel Team 
   webcit

Debian Common Lisp Team 
   clisp

Debian CORBA Team 
   omniorb-dfsg
   python-omniorb

Debian Dia Team 
   dia

Debian Games Team 
   a7xpg
   abuse-sdl
   airstrike
   asc
   billard-gl
   biniax2
   blocks-of-the-undead
   briquolo
   ceferino
   clanlib
   dopewars
   freeciv
   freedink
   gunroar
   kball
   ketm
   kraptor
   late
   lincity-ng
   liquidwar
   lordsawar
   micropolis-activity
   monsterz
   mu-cade
   netpanzer
   parsec47
   powermanga
   raincat
   renpy
   ri-li
   rroot

Orphaning mlview

[Niels Thykier]

reassign 555034 wnpp
retitle 555034 O: mlview - xml editor for GNOME environment
thanks

Hi,

I am hereby orphaning mlview[1] on behalf of Sebastian Bacher.  As it is
RC buggy and has a very low popcon, I intend to RM within 14 days unless
someone picks it up.

~Niels

[1]


Package: mlview
Version: 0.9.0-2.2
Priority: optional
Section: editors
Maintainer: Sebastien Bacher 
Depends: [...]
Description: An xml editor for GNOME environment
 Some features:

 * cut/copy/paste as child/paste as prev/paste as next/ of xml elements
 * xml element/attributes search
 * multi docs edition
 * Several editing views can be opened on the same document
 * drag and drop based copy/cut/past of xml elements
 * edition of xml elements and attributes can be made directly on the tree
 * namespace support
 * on-demand validation
 * graphical error reporting. Parse/validation time errors reported
graphically.
 * when validation is switched on, MlView proposes an
elements/attributes completion feature. When an element is added to the
tree, MlView also add the children elements required by the DTD for the
document to be valid.
 * Validation can be switched off. The xml document editon can then be
done without any constraint.


-- 
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/4eb868aa.9040...@thykier.net

Re: Release goal proposal: Archive-wide build-arch and build-indep support

[Niels Thykier]

On 2011-11-16 11:14, Goswin von Brederlow wrote:
> Niels Thykier  writes:
> 
>> On 2011-11-05 21:22, Niels Thykier wrote:
>>>
>>> Hi,
>>>
>>> I would like to propose the goal of getting archive-wide support for
>>> the optional debian/rules targets "build-arch" and "build-indep".
>>> The intention is to finally solve issues like #619284 and the goal
>>> is related to #629385.
>>>
>>> [...]
>>>
>>> To keep it attainable, the goal for Wheezy is to fix the subset of
>>> packages that would need to differentiate "build" and
>>> "build-arch"/"build-indep".  Once we have the data available, we
>>> will put up a dd-list for the reduced set.
>>>
>>> [...]
>>
>> The reduced set is available thanks to some UDD queries.  We are looking
>> at ~500 packages (see attached dd-list if some of your packages are there).
>>
>> The data is also available from[1], where you can also see the queries I
>> used to generate this set (see reduced-set.py).
>>
>>
>> Thanks for considering,
>> ~Niels
>>
>> [1] http://people.debian.org/~nthykier/rg-build-arch-target/
> 
> Have you considered (or already written) a lintian check for those
> targets?
> 
> MfG
> Goswin
> 
> 

Hi,

Beyond the existing debian-rules-missing-recommended-target, I did write
the patch in #647227.

~Niels


-- 
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/4ec38f4e.1020...@thykier.net

Orphaning emile

[Niels Thykier]

reassign 648933 wnpp
retitle 648933 O: emile -- the Early Mac Image LoadEr
severity 648933 normal
thanks


I am here by orphaning emile on behalf of the maintainers.  The
description of emile is:

"""
the Early Mac Image LoadEr

EMILE provides a way to natively boot Macintosh computers which normally
require Penguin to boot.

It is however still in an unfinished state; users unfamiliar with Linux
should note that Penguin currently is a more safe option.

A list of machines that are supported by EMILE is maintained at
http://wiki.debian.org/EmileSupportedHardware
"""

If you are interested in adopting this package, please be prepared to
fix #533800 (and #629789).  A quick look at the homepage suggests that
upstream might be dead as well.


If no one picks this package up within 14 days or so, I will push for
its removal on the grounds it that it is RC-buggy and has extremely low
popcon.

~Niels


-- 
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/4ee13d6b.5040...@thykier.net

Orphaning genesis -- general-purpose neural simulator

[Niels Thykier]

reassign 648645 wnpp
retitle 648645 O: genesis -- general-purpose neural simulator
severity 648645 normal
thanks

I am hereby orphaning genesis on behalf of its maintainer.  The
description of genesis is:

"""
general-purpose neural simulator

GENESIS is a general purpose simulation platform which was developed to
support the simulation of neural systems ranging from complex models of
single neurons to simulations of large networks made up of more abstract
neuronal components.

GENESIS has provided the basis for laboratory courses in neural
simulation at both Caltech and the Marine Biological Laboratory in Woods
Hole, MA. Most current GENESIS applications involve realistic
simulations of biological neural systems. Although the software can also
model more abstract networks, other simulators are more suitable for
backpropagation and similar connectionist modeling.
"""

If you are interested in adopting this package, please be prepared to
fix its outstanding RC bugs.


If no one picks this package up within 14 days or so, I will push for
its removal on the grounds it that it is RC-buggy.

~Niels


-- 
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/4ee141c4.3020...@thykier.net

Candidates for removal from testing

[Niels Thykier]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256


We are considering removing the following packages from testing as
they have unfixed RC bugs filed against them.  The packages can be
found in the attached dd-list (or at [0]).

The packages have been selected based on the following criteria:
 - The package had at least one RC bug without activity for the past
   14 days.
   - If a bug is assigned to multiple packages, both packages will
 be affected[1].
 - The RC bug affects both unstable and testing.
 - The affected package does not have any reverse dependencies in
   testing.

These tools[2] are rather new and therefore we have randomly chosen 10
packages from the originally generated list.  These 10 packages were
manually verified to fit the criteria listed above.  The full list
is available at [3], but has not been manually verified.


If the relevant RC bugs in the affected packages are not dealt with
before the 11th of Feb., the packages will be removed from testing.
Note that "dealt with" may also include downgrading a
severity-inflated bug or fixing affected versions in the BTS.


Thanks,
Niels (on behalf of the Release Team)

[0] http://release.debian.org/~nthykier/selected-dd-list-2012-01-25

[1] Examples include #561903 (at submission time; it was later
reassigned to a single package).

[2] The tools are available from:

svn://svn.debian.org/svn/collab-qa/rc-buggy-leaf-packages

[3] http://release.debian.org/~nthykier/rc-buggy-leaf-pkgs-dd-list-2012-01-25

Note: Some people have confused "dconf" and "d-conf" in this list.  The
former is an RC-buggy leaf package.  The latter is also RC buggy, but
has plenty of reverse dependencies (and is therefore not listed).  In
the particular case, they happen to share the same RC bug, #627508.


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

iQIcBAEBCAAGBQJPH/QfAAoJEAVLu599gGRCqd0QALCtineFuTCR5QQxKHrYACFm
Cnvidc5YkGOeP7EaxHwZOlXqM1cu0mVTZB6aRG2Ig0Qq++lV2ptKNScNUyBYDjDJ
9+c4njgAmD1Xf0MC/uBrwcapokJciq32YdKWqUKiNYHyrzauNdja1vNRtLrZiAZ7
2X3SXTy3qAW6qtGiPNdHa/vhd6a2c141Va7dzLQhy6YrAmsb2hARVP8DgM1ZInXc
u5C3dT5BPu8EoldvS/+PQU/HX/Xu1cpUDdqqKaWmyQLwGv2wHgyUXYe0vnrJG+2Z
50HhaFOZrKaqVbFY8uLCfcbRwZm2Y3WqvBI2SkZi1+z8mJ2epQEUfEU1gVHZ0SO0
N0MjfZTYOU68XhMREZ3Z/LsCcwHXJizqbzO4K+fMQE6MuxyYrAARxsfwIO+0Wfof
SE7vJzeJow7RS0C4tNFAblkd665C0nioQXiWmFiqXY6NRW4Ncmu3Aa3i96/pqhtL
uxmVS7cenIwdGsyPXPloDmKTu8niZpbbGTXvyLltA7b6bg8Eu/LnQ8T0bMG1mRgz
r7SvhyonpT5YZgTNDFhBrdUZijELWuvnFegJwPTH8Ph/mXDwM3iApm+GFJXgut8g
6nuAfmoSAw2ZT1ffliB7Eo4eSJXUaMbS1bN9z8JSxa54s6SSLrYeUN4GAQwFiKwg
pwIaprJFCC8zsWLioEAQ
=FbK3
-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/20120125122400.d24ca20131...@thykier.net

Re: Candidates for removal from testing

[Niels Thykier]

On 2012-01-26 02:45, Paul Wise wrote:
> On Thu, Jan 26, 2012 at 2:41 AM, Luk Claes wrote:
>> On 01/25/2012 01:24 PM, Niels Thykier wrote:
>>>
>>> We are considering removing the following packages from testing as
>>> they have unfixed RC bugs filed against them.  The packages can be
>>> found in the attached dd-list (or at [0]).
>>
>> For anyone who is not online the list of 10 packages is:
> 
> In future, perhaps the initial mail could contain the dd-list and also
> be CCed/BCCed to the relevant $pack...@packages.qa.debian.org
> addresses?
> 

It was my intention to include the dd-list in the original mail (but I
forgot it, thanks to Luk for adding btw).

I can BCC $p...@packages.qa.debian.org next as well if people think that is
a good idea, though I suspect a large share of people will get duplicate
emails as a result of that.

~Niels



-- 
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/4f229077.7090...@thykier.net

Re: Use of the first person in messages from the computer

[Niels Thykier]

On 2012-02-09 13:20, Ian Jackson wrote:
> I have just received a review by a l10n team of a package of mine.
> 
> The reviewer seems to be under the impression that there is something
> wrong with the computer speaking to the user in the first person.  For
> example:
> 
>> [...]

I suspect devref 6.5.2.5 is a (possible) source of this impression.  As
I recall, there are also some Lintian checks about using first person.

~Niels


-- 
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/4f33beca.4070...@thykier.net

Re: Multiarch file overlap summary and proposal

[Niels Thykier]

On 2012-02-14 07:43, Russ Allbery wrote:
> [...]
> 
> * Lintian should recognize arch-qualified override files, and multiarch:
>   same packages must arch-qualify their override files.  debhelper
>   assistance is desired for this.
> 
> [...]

I have no problem with Lintian accepting arch-qualified override files,
but I do not see the "strict" (i.e. "must") requirement[1].  Lintian
already allows you to do arch-specific overrides and 2.5.5 will even
allow architecture wildcards as well[2].


~Niels

[1] Exception being compressed override files, but of the 161 override
files on my system not a single one of them are compressed.

[2] http://lintian.debian.org/manual/section-2.4.html#section-2.4.1

Admittedly the link above does not have an example with it, but Lintian
(git) has an entire "section" dedicated to architecture specific
overrules.  So there will be several examples with next release.  :)


-- 
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/4f3a4888@thykier.net

Re: Comments+blank line in debian/control: Clarification in policy or MBF?

[Niels Thykier]

On 2012-10-03 11:01, Michael Tautschnig wrote:
> [...]
> 
> But then either all build infrastructure (and also lintian) don't use
> debian/control, or all these tools tolerate that blank line (with the 
> exception
> of pbuilder).
> 
> Best,
> Michael
> 

Lintian's parser ignores empty lines before/between paragraphs.

~Niels


-- 
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/506c09da.7020...@thykier.net

Re: Comments+blank line in debian/control: Clarification in policy or MBF?

[Niels Thykier]

On 2012-10-03 12:02, Michael Tautschnig wrote:
>> On 2012-10-03 11:01, Michael Tautschnig wrote:
>>> [...]
>>>
>>> But then either all build infrastructure (and also lintian) don't use
>>> debian/control, or all these tools tolerate that blank line (with the 
>>> exception
>>> of pbuilder).
>>>
>>> Best,
>>> Michael
>>>
>>
>> Lintian's parser ignores empty lines before/between paragraphs.
>>
> 
> I suppose that piece of code is quite dated. Is there a way to figure out why
> lintian does this, i.e., who decided to interpret policy in this way?
> 
> Best,
> Michael
> 


The code basically the same now as it was in Oct 1998.  From the Lintian
changelog, I am guessing the code was written in the 0.3.0 upload (from
March 1st, 1998) or in the 0.4.0 (April 6th, same year).  However,
neither change have a bug associated with the changes[1] and I not aware
of any copy of either of those versions still existing.

While I cannot say for certain, I am guessing it is side effect and not
intentional[2].

~Niels

[1]

0.3.0 entry:
  * Internal changes:
[...]
  - implemented dpkg_read_control to parse all controls

0.4.0 entry
  * Internal: fixed bug in read_dpkg_control() utility function: empty
tags have not been handled correctly

If you go hunting for you, it will probably appear in lib/util.pl
(source) or /usr/share/lintian/lib/util.pl (binary).

[2] My guess is based on the following observation.

The parser is used for signed (and unsigned) control files, so it has
code for handling the presence of the signature.  More specifically, it
checks for a line starting with "-BEGIN PGP" (that isn't "BEGIN PGP
SIGNATURE").  FTR the parser has never enforced that the marker appears
on the first line if at all.

In the current versions it will ignore lines up to the first empty line
after the PGP marker, but in the 0.9.3 version it doesn't.  So the 0.9.3
parser would pick up the the "Hash: SHA256" field as the first paragraph
in the following:

  """
  -BEGIN PGP SIGNED MESSAGE-
  Hash: SHA256

  Format: ...
  """

Assuming GPG/PGP was not adding fields after the "SIGNED MESSAGE" marker
back then, it would make sense for the code to ignore an empty line
before the first paragraph as a way to handle the empty line after the
"SIGNED MESSAGE" marker.

Indeed, if you look at the Lintian 0.9.3 dsc[LDSC] it does not have any
"GPG fields" in it at the first marker.  Instead they appear after the
"SIGNATURE" marker, so that /could/ be the logic behind it.

[LDSC]
http://snapshot.debian.org/archive/debian-archive/20090802T004153Z/debian/dists/slink/main/source/devel/lintian_0.9.3.dsc

Oh look, no Build-Depends... XD


-- 
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/506c1ab9.2060...@thykier.net

Candidates for removal from testing

[Niels Thykier]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256


Hi,

We are considering removing the following packages from testing as
they have unfixed RC bugs filed against them. The packages can be
found in the attached dd-list.  The bugs that put them on this list
can be found in the removals file (also attached) just above the
package name.

The packages have been selected based on the following criteria:
 * The package had at least one RC bug without activity for the past
   14 days.
 * If a bug is assigned to multiple packages, both packages will be
   affected.
 * The RC bug affects both unstable and testing.
 * The affected package does not have any reverse dependencies in
   testing.

If the relevant RC bugs in the affected packages are not dealt with
/before/ Friday the 26th of Oct., the packages will be removed from
testing.  Note that "dealt with" may also include downgrading a
severity-inflated bug or fixing affected versions in the BTS.

Please remember to file unblock bugs for packages fixed via uploads to
unstable (and tpu bugs for requests to fix the package via a tpu
upload).

Should you need a bit more time than given, please do not hesitate to
contact us.  It is also easier for us if we can avoid having to
reintroduce a removed package.

We will check the DELAYED queues before activing the removal hints, so
NMUs in the DELAYED queues will be given a chance to reach unstable.

Thanks,
Niels (on behalf of the Release Team)

The bugs were found using the tools from:
  svn://svn.debian.org/svn/collab-qa/rc-buggy-leaf-packages


http://release.debian.org/wheezy/freeze_policy.html

  --8<8<-- dd-list --8<8<--
Aleksey Kravchenko 
   rhash

Alessio Treglia 
   beast (U)

Andres Mejia 
   firmware-crystalhd

Andrew Pollock 
   barada-pam

Anibal Avelar 
   pidgin-sipe

Antonio Radici 
   cfengine3

Barak A. Pearlmutter 
   ilisp

Bradley Bell 
   rt-extension-assettracker (U)

Chris Lamb 
   fabric

Christoph Berg 
   dacs

Daniel Kahn Gillmor 
   vblade-persist

Daniel Kobras 
   noflushd

David Gil 
   phpgacl

David Paleino 
   spatialite-gui (U)

Debian GIS Project 
   spatialite-gui

Debian Hamradio Maintainers 
   ax25-apps

Debian Lustre Packaging team 
   lustre

Debian Med Packaging Team 
   gentle

Debian Mozilla Extension Maintainers 

   venkman

Debian Multimedia Maintainers 

   beast

Debian OCaml Maintainers 
   mingw-ocaml

Debian OLPC 
   sugar-chat-activity-0.86
   sugar-log-activity-0.86
   sugar-moon-activity

Debian Perl Group 
   libio-async-loop-epoll-perl

Debian Python Modules Team 
   python-django-piston
   python-gnupg (U)
   sorl-thumbnail

Debian Request Tracker Group 

   rt-extension-assettracker

Debian Ruby Extras Maintainers 

   camping

Debian Xfce Maintainers 
   gigolo

Dipankar Patro 
   sugar-log-activity-0.86 (U)

Dominic Hargreaves 
   rt-extension-assettracker (U)

Drew Parsons 
   zangband

Eduard Bloch 
   icewm-themes

Elena Grandi 
   python-gnupg

Emanuele Rocca 
   gigolo (U)

Emmanuel Lacour 
   mod-proxy-html

Fabrizio Regalli 
   venkman (U)

Giuseppe Iuculano 
   smbind

gregor herrmann 
   libio-async-loop-epoll-perl (U)

Hamish Moffatt 
   ax25-apps (U)

Ishan Bansal 
   sugar-moon-activity (U)

Jaime Robles 
   ax25-apps (U)

Jakub Adam 
   pidgin-sipe (U)

Javier Fernandez-Sanguino Pen~a 
   phpgacl (U)

Javier Fernandez-Sanguino Pen~a 
   openvas-plugins-dfsg

Javier Fernández-Sanguino Peña 
   openvas-plugins-dfsg

Jean-Louis Dupond 
   remmina (U)

Joerg Jaspert 
   mailfilter

Joey Schulze 
   php-crypt-gpg

John Goerzen 
   twidge

Jonas Smedegaard 
   sugar-chat-activity-0.86 (U)

Jonathan Yu 
   libio-async-loop-epoll-perl (U)

Luca Falavigna 
   remmina

Luke Faraone 
   sugar-log-activity-0.86 (U)
   sugar-moon-activity (U)

Marcelo Jorge Vieira (metal) 
   scuttle

Martin Zobel-Helas 
   dacs (U)

Matthew Vernon 
   trn

Michael Fladischer 
   sorl-thumbnail (U)

Michael Hanke 
   fsl (U)

Michael Ziegler 
   python-django-piston (U)

NeuroDebian Team 
   fsl

Nicholas Bamber 
   maradns

Noèl Köthe 
   lustre (U)

Patrick Ouellette 
   ax25-apps (U)

Patrick Winnertz 
   lustre (U)

Paul van Tilburg 
   camping (U)

Pierre Chifflier 
   inguma

Ramakrishnan Muthukrishnan 
   ax25-apps (U)

Ricardo Mones 
   mailfilter (U)

Romain Beauxis 
   mingw-ocaml (U)

Rémi Denis-Courmont 
   miredo

Sam Hocevar (Debian packages) 
   beast (U)

Simon Huggins 
   gigolo (U)

Stefan Ott 
   gigolo (U)

Stefan Völkel 
   revelation

Steffen Moeller 
   gentle (U)

Thibaut Gridel 
   routino

Thomas Goirand 
   extplorer

Uwe Steinmann 
   routino (U)

Werner Jaeger 
   l2tp-ipsec-vpn

Yaroslav Halchenko 
   fsl (U)

Yves-Alexis Perez 
   gigolo (U)

  --8<8<-- end of dd-list --8<8<--

  --8<8<-- removals --8<8<--
# #630893
remove ax25-apps/0.0.8-rc2+cvs20120204-2

# #678968
remove barada-pam/0.5-3.1

# #674900/#687397
remove beast/0.7.4-4

# #689038
remove camping/2.1.498-3

# #688267
remove cfengine3/3.2.4-2

# #689541
r

Re: Candidates for removal from testing

[Niels Thykier]

On 2012-10-19 17:43, Wouter Verhelst wrote:
> On Thu, Oct 18, 2012 at 10:32:39AM +0200, Niels Thykier wrote:
>> We are considering removing the following packages from testing as
>> they have unfixed RC bugs filed against them. The packages can be
>> found in the attached dd-list.  The bugs that put them on this list
>> can be found in the removals file (also attached) just above the
>> package name.
> [...]
> 
> Shouldn't this have gone to debian-devel-announce instead?
> 

We have been using d-d for these mails every since we introduced
them[0][1], so the destination was intentionally d-d.
  That said, I do not (personally) have any strong feelings for or
against using d-d-a given the current rate at which we produce these
lists.  However, it is my understanding that we intended to do them
vastly more frequently than we are now[2].

If you are concerned about people not being subscribed to d-d getting
their packages removed, then I have (despite not adding it to the
original mail) Bcc'ed $pack...@packages.debian.org.  So the maintainers
should have gotten the heads up[3].

On the other hand, if you were missing something like "Bits from the RT"
then you are probably right.  I think we have been pretty much drowning
in unblocks and haven't had time to do a bits mail.

~Niels

[0] https://lists.debian.org/debian-devel-announce/2011/08/msg0.html

[1] https://lists.debian.org/debian-devel-announce/2012/01/msg9.html

and https://lists.debian.org/debian-devel/2012/01/msg00653.html

[2] The original mail[0] even go so far to suggest "daily".  I am not
certain that will happen with the current level of manual
work/filtering.  However, weekly or bi-weekly is not out of the question.

[3] Though, 4 team lists put my mail in the "needs moderator approval"
(for various reasons), so I hope their list moderators are not too
inactive.  :)


-- 
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/50817bfd.4050...@thykier.net

Re: Candidates for removal from testing (results)

[Niels Thykier]

On 2012-10-18 10:32, Niels Thykier wrote:
> 
> Hi,
> 
> [...]
> 
> If the relevant RC bugs in the affected packages are not dealt with
> /before/ Friday the 26th of Oct., the packages will be removed from
> testing.  Note that "dealt with" may also include downgrading a
> severity-inflated bug or fixing affected versions in the BTS.
> 

Britney has just finished removing the following 21 packages:

ax25-apps, fabric, firmware-crystalhd, icewm-themes, ilisp, inguma,
lustre, mingw-ocaml, noflushd, openvas-plugins-dfsg, php-crypt-gpg,
phpgacl, python-django-piston, smbind, sorl-thumbnail, spatialite-gui,
sugar-chat-activity-0.86, sugar-log-activity-0.86, sugar-moon-activity,
twidge, venkman

The removed packages accounted for about 4.4% of all RC bugs left in
testing[0].

> [...]
> 
> Should you need a bit more time than given, please do not hesitate to
> contact us.  It is also easier for us if we can avoid having to
> reintroduce a removed package.
> 
> [...]

We got about 3 or 4, who took advantage of this offer.  I also noticed
two bug reports with a promise of a (N)MU in the report, which I left
for now[1].

By my count 5 RC bugs got downgraded and about packages 14 got an upload
to unstable (most of which have already been unblocked).

~Niels

[0]
According to [BTS-RC], there were 479 RC bugs concerning testing at 6 am
UTC.  Assume that each package only had 1 RC each, 21/479 ~~ 4.4%

[BTS-RC] http://bugs.debian.org/release-critical/

[1] But I intend check up on them.


-- 
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/508a67f2.7010...@thykier.net

Candidates for removal from testing (2012-10-30)

[Niels Thykier]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi,

We are considering removing the following packages from testing as
they have unfixed RC bugs filed against them. The packages can be
found in the attached dd-list.  The bugs that put them on this list
can be found in the removals file (also attached) just above the
package name.  We have BCC'ed this email to @packages.debian.org
for the relevant packages.

The packages have been selected based on the following criteria:
 * The package had at least one RC bug without activity for the past
   14 days.
 * If a bug is assigned to multiple packages, both packages will be
   affected.
 * The RC bug affects both unstable and testing.
 * The affected package does not have any reverse dependencies in
   testing.

If the relevant RC bugs in the affected packages are not dealt with
/before/ Wednesday the 7th of Nov.[1], the packages will be removed
from testing.  Note that "dealt with" may also include downgrading a
severity-inflated bug or fixing affected versions in the BTS.

Please remember to file unblock bugs for packages fixed via uploads to
unstable (and tpu bugs for requests to fix the package via a tpu
upload).

Should you need a bit more time than given, please do not hesitate to
contact us.  It is also easier for us if we can avoid having to
reintroduce a removed package.

We will check the DELAYED queues before activing the removal hints, so
NMUs in the DELAYED queues will be given a chance to reach unstable.

Thanks,
Niels (on behalf of the Release Team)

The bugs were found using the tools from:
  svn://svn.debian.org/svn/collab-qa/rc-buggy-leaf-packages


http://release.debian.org/wheezy/freeze_policy.html


[1] We intend to do the removal with the 10:00 UTC run of Britney of
that day.


 --8<-- dd-list --8<--
Aurélien GÉRÔME 
   dancer-ircd

Al Stone 
   lmbench

Chris Lamb 
   python-django-extensions

Debian PHP Maintainers 
   xcache (U)

Debian XMPP Maintainers 
   jabber-muc

Ghe Rivero 
   quantum (U)

Jesus Climent 
   distmp3

Jorge Salamero Sanz 
   jabber-muc (U)

Jose Luis Tallon 
   couriergraph

Julien Danjou 
   quantum (U)

Kai Storbeck 
   roundup

Loic Dachary (OuoU) 
   quantum (U)

Ludovic Brenta 
   polyorb (U)

Martin Loschwitz 
   ircd-ircu

Mehdi Abaakouk 
   quantum (U)

Michal Čihař 
   xcache

Mike Markley 
   dk-milter

Peter Krefting 
   lyskom-server

PKG OpenStack 
   quantum

Thomas Goirand 
   quantum (U)

Toni Mueller 
   roundup (U)

Xavier Grave 
   polyorb
 --8<-- end of dd-list --8<--

 --8<-- removals.txt --8<--
# #689884
remove couriergraph/0.25-4.1

# #689886
remove dancer-ircd/1.0.36-8

# #689887
remove distmp3/0.1.9.ds1-4.4

# #689888
remove dk-milter/1.0.0.dfsg-1.2

# #689893
remove ircd-ircu/2.10.12.10.dfsg1-1

# #689894
remove jabber-muc/0.8-3

# #689897
remove lmbench/3.0-a9-1

# #689898
remove lyskom-server/2.1.2-12

# #688299
remove polyorb/2.8~20110207-4

# #690425
remove python-django-extensions/0.6+git201107051902-1

# #685251
remove quantum/2012.1-5

# #689257
remove roundup/1.4.20-1

# #690409
remove xcache/2.0.0-2

 --8<-- end of removals.txt --8<--
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)

iQIcBAEBCAAGBQJQj9XpAAoJEAVLu599gGRCilQP/0Pzrbiq2Qi5xRdN2Auk7mzr
Clqbt9nStd0ZDR6ju2lxVj9emkOIRMUAp5Oq2c/+lC5pg2+AgZD57ijKMJqJLDTM
o8Fr8oIVdAcyMgNt7hKo8vXcIz0gBh6qwLWRXdR37pTd4jNqjCGnTtxbS5ZMIcz0
x9J2LjvIPLE+KEsjmAw185W8YVvvkaqVQqfwQ6K0xGdXvv23gfhlimlFHQUs8ElG
yljmcRl0e+xBlFxa+zmueBeAPcwPCjUv5haJQWXEZVUjxXezO4FEdwcHZFDeLKYy
1DzpOFcd6wycjqsdizQQtzNGGF726Fdj2nSKc7RjZ2oMr34lYQPKgN233t+QK8f9
aHatHySzcj6etlmsjdHmHreSnzzMxrf08OqWKW8O7AmrWkUdWnQFnUuDXc1A+Dwf
ESBG51fbHVj/wCNQ3vq9WyNwZpXqn2VxtHceMhiNdjbjkh/hjr2/k6hUeLADxBqG
dwwLA1p3UVk35R19rk5C2qaJIV8INZXfnsg7qZ7rS+JoO0+ZNyRwbxQFuE6Wf1+2
fAvyjmB6qiqHoZ+tSBP44PTzN2uPofZbfe6GTcRVQGJW3JxUSNmjNgefAmXl5367
KJxQKhb6Y3fDbWEl+sum6cV5QMriPxtNY8NnaEBgeGlzWFSlI5s+ozMUrSOTKOV/
E6STJCINXJEOKmcx1ogj
=4EtK
-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/20121030133215.e95cf3...@thykier.net

Re: Candidates for removal from testing (results)

[Niels Thykier]

On 2012-10-28 18:47, Stefano Zacchiroli wrote:
> On Fri, Oct 26, 2012 at 12:37:38PM +0200, Niels Thykier wrote:
>> ax25-apps, fabric, firmware-crystalhd, icewm-themes, ilisp, inguma,
>> lustre, mingw-ocaml, noflushd, openvas-plugins-dfsg, php-crypt-gpg,
>> phpgacl, python-django-piston, smbind, sorl-thumbnail, spatialite-gui,
>> sugar-chat-activity-0.86, sugar-log-activity-0.86, sugar-moon-activity,
>> twidge, venkman
>>
>> The removed packages accounted for about 4.4% of all RC bugs left in
>> testing[0].
> 
> Thanks a lot, Neil! Is that something that you plan to automate further
> (at least the "warning" mails, I understand you probably want to further
> inspect the individual removals), and/or run on a fixed cadence?
> 

I have just send another round (only 13-14 packages this time).  I hope
I can keep it at once per week for the rest of the freeze (or till we
run out of RC buggy leaf packages).

Though I am not sure whether to keep the rate this high outside freeze.
 Maybe keep the rate with higher deadline or slow down to (e.g.)
bi-weekly mails...  Anyway, we can look at that once development of
Jessie starts. :)

~Niels


-- 
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/508fda1c.3090...@thykier.net

Re: Candidates for removal from testing (results)

[Niels Thykier]

On 2012-10-30 14:32, Niels Thykier wrote:
> Hi,
> 
> [...]
>
> If the relevant RC bugs in the affected packages are not dealt with
> /before/ Wednesday the 7th of Nov.[1], the packages will be removed
> from testing.  Note that "dealt with" may also include downgrading a
> severity-inflated bug or fixing affected versions in the BTS.
> 
> [...]

A few hours ago Britney removed the following 6 packages: distmp3,
dk-milter, jabber-muc, lmbench, lyskom-server and
python-django-extensions.

> 
> Should you need a bit more time than given, please do not hesitate to
> contact us.  It is also easier for us if we can avoid having to
> reintroduce a removed package.
> 
> We will check the DELAYED queues before activing the removal hints, so
> NMUs in the DELAYED queues will be given a chance to reach unstable.
> 

3 packages were fixed before the deadline and 1 is currently in DELAYED
with less than 8 hours to go.

#690409 got tagged moreinfo + unreproducible and received some debate.
#685251 got downgraded but was upgraded yesterday.  A fix for #688299
was uploaded, but it was incomplete and the bug was re-opened.
  All three bugs remain open in Wheezy and I will keep an eye on them
for now.


~Niels



-- 
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/509a545b.50...@thykier.net

Candidates for removal from testing (2012-11-14)

[Niels Thykier]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi,

We are considering removing the following packages from testing as
they have unfixed RC bugs filed against them. The packages can be
found in the attached dd-list.  The bugs that put them on this list
can be found in the removals file (also attached) just above the
package name.  We have BCC'ed this email to @packages.debian.org
for the relevant packages.

The packages have been selected based on the following criteria:
 * The package had at least one RC bug without activity for the past
   14 days.
 * If a bug is assigned to multiple packages, both packages will be
   affected.
 * The RC bug affects both unstable and testing.
 * The affected package does not have any reverse dependencies in
   testing.

If the relevant RC bugs in the affected packages are not dealt with
/before/ Wednesday the 22nd of Nov.[1], the packages will be removed
from testing.  Note that "dealt with" may also include downgrading a
severity-inflated bug or fixing affected versions in the BTS.

Please remember to file unblock bugs for packages fixed via uploads to
unstable (and tpu bugs for requests to fix the package via a tpu
upload).

Should you need a bit more time than given, please do not hesitate to
contact us.  It is also easier for us if we can avoid having to
reintroduce a removed package.

We will check the DELAYED queues before activing the removal hints, so
NMUs in the DELAYED queues will be given a chance to reach unstable.

Thanks,
Niels (on behalf of the Release Team)

The bugs were found using the tools from:
  svn://svn.debian.org/svn/collab-qa/rc-buggy-leaf-packages


http://release.debian.org/wheezy/freeze_policy.html


[1] We intend to do the removal with the 10:00 UTC run of Britney of
that day.


 --8<-- dd-list --8<--
Alexander Wirt 
   ferm

Cameron Dale 
   apt-p2p

Debian Sympa team 
   sympa

Emmanuel Bouthenot 
   sympa (U)

Jonas Smedegaard 
   sympa (U)

Jonathan Wiltshire 
   mediawiki-math (U)

Mediawiki Maintenance Team 
   mediawiki-math

Stefan Hornburg (Racke) 
   sympa (U)

 --8<-- end of dd-list --8<--

 --8<-- removals.txt --8<--
# #635969/#641732
remove apt-p2p/0.1.6

# #688377
remove ferm/2.1-2

# #689249
remove mediawiki-math/2:1.0+git20120528-5

# #686846
remove sympa/6.1.11~dfsg-4

 --8<-- end of removals.txt --8<--
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)

iQIcBAEBCAAGBQJQo/9WAAoJEAVLu599gGRCYEwQAKgzvM4ZMKTKtQ39cAyDPfi4
y+z/oDVCEL3ES8MqEh7IuEQ7p0ZPvf9XlIrshCodOtPGZxQT4yhbFDsAQYURW1Jg
1YsuK53iQYhl+Wj/TQX5NBcKfA0xIqiM3dSEDPBtdxen5ZO1YWE3jxCA75T5mrrt
YuNEt1PlftWGdTzqqXt8b8L6Ol6/CGk1cUaZJTbDqiwuTlplYsfOL+3Nyj2PallB
MHgF8JnO3lAxnNSIbYTjdn8zhshDBsRBO3sgRoUcjxS/RJw9IPaaaU+RxuTjGc9X
ZYN8gwlXuC0AJYkhZ/qbczig9t8Tk+OzIPI2TOJtXr1tJITOOFSPPNdjm5Tg7PJC
HvyiYWxLsBzYx7fLBzMJf3FNv6o9N9EHNYDIvgmm/XQVHGcyt8aaNfqgbojEEr0U
mNQrzxk2yXxsi+R3jiOYwBlapq6PIv+V+APtvmusQ0bvL9is5CZ8LuF5tZrpAe1j
XrurYCdXHKL1tvAZ+GRECEmmFLvdO/kgmJJ2IdoJsTyabXXxNDXxJYBhJw6tNCOr
hXYNwD5XnQD9/h0stvhHm+/k9gFHBO+UHj+Iu44E27VLHofRqKtlM008rqDVkPjx
TjHVZ+FjnHRuvH+4hSxM18tsNc7xyY3yH/IthnLJKbyy5m+b992P/AFq15fQV08n
pu/RtgutvHSDPm1v1Zkg
=X/gb
-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/20121114210210.c22f13e...@thykier.net

Re: Candidates for removal from testing (2012-11-14)

[Niels Thykier]

On 2012-11-15 00:15, Emmanuel Bouthenot wrote:
> Hi,
> 
> On Wed, Nov 14, 2012 at 10:02:10PM +0100, Niels Thykier wrote:
> [...]
> 
>> Should you need a bit more time than given, please do not hesitate to
>> contact us.  It is also easier for us if we can avoid having to
>> reintroduce a removed package.
> [...]
> 
>> Debian Sympa team 
>>sympa
>>
>> Emmanuel Bouthenot 
>>sympa (U)
> 
> As said in the bug report[1], I'm currently working on fixing this bug
> but I might need more time to finish writing some tests to be sure that
> the fix is correct.
> 
> Is it possible to relax the deadline?
> 
> 
> [1] http://bugs.debian.org/686846
> 
> Regards,
> 

Certainly, do you have a rough idea of how long you will need?

~Niels


-- 
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/50a4b91e.6030...@thykier.net

Re: Candidates for removal from testing (results)

[Niels Thykier]

On 2012-11-14 22:02, Niels Thykier wrote:
> Hi,
> 
> We are considering removing the following packages from testing as
> they have unfixed RC bugs filed against them. [...]
>

ferm, apt-2p2 and mediawiki-math has been fixed in sid and by the looks
of it all of them are already unblocked.

> Should you need a bit more time than given, please do not hesitate to
> contact us.  It is also easier for us if we can avoid having to
> reintroduce a removed package.
> 
> [...]
>

sympa got a deadline extension.

> Thanks,
> Niels (on behalf of the Release Team)
> 
> [...]

So no removals in this round! \o/

~Niels


-- 
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/50ac8507.9070...@thykier.net

Candidates for removal from testing (2012-11-30)

[Niels Thykier]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi,

We are considering removing the following packages from testing as
they have unfixed RC bugs filed against them. The packages can be
found in the attached dd-list.  The bugs that put them on this list
can be found in the removals file (also attached) just above the
package name.  We have BCC'ed this email to @packages.debian.org
for the relevant packages.

The packages have been selected based on the following criteria:
 * The package had at least one RC bug without activity for the past
   14 days.
 * If a bug is assigned to multiple packages, both packages will be
   affected.
 * The RC bug affects both unstable and testing.
 * The affected package does not have any reverse dependencies in
   testing.

If the relevant RC bugs in the affected packages are not dealt with
/before/ Saturday the 08th of Dec.[1], the packages will be removed
from testing.  Note that "dealt with" may also include downgrading a
severity-inflated bug or fixing affected versions in the BTS.

Please remember to file unblock bugs for packages fixed via uploads to
unstable (and tpu bugs for requests to fix the package via a tpu
upload).

Should you need a bit more time than given, please do not hesitate to
contact us.  It is also easier for us if we can avoid having to
reintroduce a removed package.

We will check the DELAYED queues before activing the removal hints, so
NMUs in the DELAYED queues will be given a chance to reach unstable.

Thanks,
Niels (on behalf of the Release Team)

The bugs were found using the tools from:
  svn://svn.debian.org/svn/collab-qa/rc-buggy-leaf-packages


http://release.debian.org/wheezy/freeze_policy.html


[1] We intend to do the removal with the 10:00 UTC run of Britney of
that day.


 --8<-- dd-list --8<--
Barak A. Pearlmutter 
   fossil

Debian dsc Maintainer Team 
   dsc-statistics

Debian Forensics 
   unhide.rb

Debian GNOME Maintainers 
   gnome-dvb-daemon (U)

Julien Valroff 
   unhide.rb (U)

Marc Haber 
   dsc-statistics (U)

Sebastian Dröge 
   gnome-dvb-daemon (U)

Sebastian Laubscher 
   dsc-statistics (U)

Sebastian Reichel 
   gnome-dvb-daemon

 --8<-- end of dd-list --8<--

 --8<-- removals.txt --8<--
# #668740/#668740
remove dsc-statistics/201203250530-1

# #692623
remove fossil/1:1.22.1-1

# #683012/#683013
remove gnome-dvb-daemon/1:0.2.8-1

# #677650
remove unhide.rb/13-1

 --8<-- end of removals.txt --8<--

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

iQIcBAEBCAAGBQJQuJ4BAAoJEAVLu599gGRCrAoP/iu+6bjDB81S3MnTuO5b9kQo
F6rWCq7iAzGYyCmXCuRY3QXVw3uB55Yh0jbEuyN7GqYDIV682Kbjk4HnPXopauRV
LWmh4u5Ezh8ILmomdoCa7E+2Wx0Ky5yvcf7v/53kGclX1EvxmJTJgL3Ef/AMRK5H
FNcdzPIGIDH4Z6nJzwRKAN1yLz3NujAD106AoUj0WP9SLDVYRSzUb9Yw78vXoxCz
84mj/YjKD8NmBjltVl931kvXanK1EuYxT0XjMgGOa0c0L2UIyNmnFEdIJGnerNub
W7LPv4z50qOqYAI2fcuu8vStKWYvLdA6DJOZe6szgD+YaPORic/nzdw+mDwATroe
MbXYRDv6cFbdSQBjElwzPFC/Pfie6MRr1fk5GG8gcjWKP++uuA4NXgu3/3deRCya
YcFzBellCLOeNaTFNXzRC2czYE/m8Yvx6gymJ/Mu57CGs34NKx6NwL5Wjmd2ZgeZ
+u8+C8hXKrzP9oFfwPruirnyUKgg8R3gWyrFDfCOG2hAVDHjki+nAE+iF2uuAwqF
kpgprYGq/V1VrVHAncxeLrGPbPQeatCJwRUMxGj10sbQyPiRcFjbEVDZZhkfwtns
ihdSjiWoDnBEgncmxwY0B++LrAA4+E/iSrPavATGfVwfAXi6fgg/l5HnQxX/Y8rT
8VOq1DuhkhmfBzGjwbjW
=ON1Q
-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/20121130115535.d465f...@thykier.net

Re: Candidates for removal from testing (results)

[Niels Thykier]

On 2012-11-30 12:55, Niels Thykier wrote:
> [...]
> 

While slightly overdue; the results were 0 removals! \o/

> 
>  --8<-- removals.txt --8<--
> # #668740/#668740
> remove dsc-statistics/201203250530-1
> 

Downgraded.

> # #692623
> remove fossil/1:1.22.1-1
> 

Fixed in sid and wheezy (via t-p-u)

> # #683012/#683013
> remove gnome-dvb-daemon/1:0.2.8-1
> 

Still open, but caused by an ABI affecting multiple packages.  This one
should not have been on the list originally; poor manual filtering
(sorry for that).

> # #677650
> remove unhide.rb/13-1
> 
> [...]

Fix in sid already unblocked.


In order news, the tools for finding RC buggy leaf packages says we have
run out of leaf packages (for now at least).  So there will be no new
list today.  Hopefully it stays that way  :)


Thank you,
~Niels




-- 
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/50c3d451.2010...@thykier.net

Re: Multiple source package entries in Sources file

[Niels Thykier]

On 2012-12-18 16:01, Simon Kainz wrote:
> So whats the point in having multiple versions of the same source package?
> I'm really interested in the background if this issue.
> 
> Thanks in advance!
> 
> Regards,
> 
> Simon


Besides build failures (as suggested by Roland and Stuart), there is
also a talk about keeping old versions of the source package around for
license compliance.  This is mostly related to packages "embedding"
(parts of) other packages during builds (I believe they would use the
Built-Using header to declare this).

To knowledge, dak does not expose these extra sources yet.  However, I
believe it is the plan to eventually do so.

~Niels


-- 
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/50d0951e.6050...@thykier.net

Candidates for removal from testing (2013-01-24)

[Niels Thykier]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi,

We are considering removing the following packages from testing as
they have unfixed RC bugs filed against them. The packages can be
found in the attached dd-list.  The bugs that put them on this list
can be found in the removals file (also attached) just above the
package name.

The packages have been selected based on the following criteria:
 * The package had at least one RC bug without activity for the past
   14 days.
 * If a bug is assigned to multiple packages, both packages will be
   affected.
 * The RC bug affects both unstable and testing.
 * The affected package does not have any reverse dependencies in
   testing.

If the relevant RC bugs in the affected packages are not dealt with
/before/ Thursday the 31th of Jan., the packages will be removed from
testing.  Note that "dealt with" may also include downgrading a
severity-inflated bug or fixing affected versions in the BTS.

Please remember to file unblock bugs for packages fixed via uploads to
unstable (and tpu bugs for requests to fix the package via a tpu
upload).

Should you need a bit more time than given, please do not hesitate to
contact us.  It is also easier for us if we can avoid having to
reintroduce a removed package.

We will check the DELAYED queues before activing the removal hints, so
NMUs in the DELAYED queues will be given a chance to reach unstable.

Thanks,
Niels (on behalf of the Release Team)

The bugs were found using the tools from:
  svn://svn.debian.org/svn/collab-qa/rc-buggy-leaf-packages


http://release.debian.org/wheezy/freeze_policy.html

  --8<8<-- dd-list --8<8<--
Debian Java Maintainers 
   jenkins

Debian QA Group 
   bzr-gtk

James Page 
   jenkins (U)

Pierre Chifflier 
   glpi

Romain Beauxis 
   lastfmproxy

Wouter Verhelst 
   pmw

  --8<8<-- end of dd-list --8<8<--

  --8<8<-- removals --8<8<--
# #697402
remove bzr-gtk/0.103.0+bzr792-3

# #694642
remove glpi/0.83.31-1

# #696816
remove jenkins/1.447.2+dfsg-2

# #694589
remove lastfmproxy/1.3b-2

# #696844
remove pmw/1:4.24-1

  --8<8<-- end of removals --8<8<--
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)

iQIcBAEBCAAGBQJRAUhvAAoJEAVLu599gGRCdKoP/AouibtJnE4H4MGdGNxU4rJE
G4kJaeqpR/aeKBiti30eXdUwKLfMNGE2dFqbrp0Wgp/YSE+vr22JyqyC43AHoKkD
dLhpqcnFVKfQe97MvsdbVel6Ox5x45wwGFqkO5HwT6M5cLc9RClCm7sA0XyCsinQ
dmq3nR0tJW9pfnTm97bwCRmisJ9DwVxtgjKqr082sfQFsUOkZP7OpM2q0ZDtwC84
X4/P+7rHSOor8Evj8lE75fN4rXu0e4bjq98yRprRuHHyWLSmqpuvFpniBlQFmsI3
kdMv2r5WL6NU3bT6IGDhjcx4gq8FouRbKYyTybhua2J8Ez9bkp4gbR5VMh3nmIrI
e7BI0UEWIeYz2TmyclSp/1DCjQY+Rl9NmTJpklcJuAUgtDHt2pZCnVemz/iEvkjv
mZbVhynfNeZrnlR0KQGQXdshm2K2amF0WoF9as71vU9EqMUI2DXiD8fDTgtQa2+B
YuP1Pk5hEko5A9c9tAjSNfEOjnLaFfbUfW1+5gCplzF7Vd4FcY5JTiAKzOliwPpD
lMrPL5XTgUDfz6d9sW2aGA2Iyk6ruhDk0d98YcpmviQE72aTyHuZ8m97zqhAprdt
eaCD56R3TJfr2DKRh6933Ccq7AtLcUx4asOCZV6myEFKSg4kMd5LEAyVlziNYxxx
Gp5OZE+O4xLtiMtU+MUy
=/0Pa
-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/20130124144708.58796200ff...@thykier.net

Re: Candidates for removal from testing results)

[Niels Thykier]

On 2013-01-24 15:47, Niels Thykier wrote:
> [...]
> # #697402
> remove bzr-gtk/0.103.0+bzr792-3
> 

Reassigned to python and downgraded.

> # #694642
> remove glpi/0.83.31-1
> 

Fixed in sid and downgraded.

> # #696816
> remove jenkins/1.447.2+dfsg-2
> 

Fixed in sid.

> # #694589
> remove lastfmproxy/1.3b-2
> 

Removed from testing.

> # #696844
> remove pmw/1:4.24-1
> 

Downgraded to important.

~Niels


-- 
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/510a3196.5060...@thykier.net

Re: openjdk maintenance for wheezy and squeeze

[Niels Thykier]

On 2013-02-18 13:08, Steven Chamberlain wrote:
> [...]
>> OpenJDK6 therefore should be considered obsolete when Wheezy is released.
> 
> I wouldn't use the word 'obsolete' so long as there are packages that
> *can* use it...  I'd call it 'maintenance only'.
> 
> 
> Before deciding the post-wheezy fate of openjdk-6, why not wait, and see
> how well things work out over the next few months.  Let's see what
> security issues affect openjdk-6 vs. openjdk-7.  Let's see how Red Hat's
> security maintenance for openjdk-6 compares to Oracle's own Java 7 fixes
> being pulled into openjdk-7 (in terms of expediency, complexity of
> changes, regressions).
> 

Well, that being a fair argument - however, are you volunteering to
(co-)maintain OpenJDK-6 while we found out?  And even if it turns out to
be worse?  I know I can't answer yes to either myself.
  That is why I support getting rid of OpenJDK-6 ASAP[0]; to ease the
maintaince burden for the OpenJDK maintainers.

> For example, if I had some public-facing Java-based service, I would
> rather have been running it on openjdk-6 over the past months because it
> had fewer security issues and perhaps no regressions caused by fixes.
> 

As far as I know, the recent "flood" of CVEs affect OpenJDK-6 as well.
Compare [1] with [2] - the majority of the CVEs starting at
"CVE-2012-1531" and "down" appear to be almost identical.

> OTOH some packages may switch to openjdk-7 post-wheezy or ship a new
> upstream version that has at least been fixed to be able to use it.
> 
> Regards,

~Niels

[0] ASAP being post-wheezy AFAICT, see:

<512162ec.9040...@thykier.net>

[1] https://security-tracker.debian.org/tracker/source-package/openjdk-6

[2] https://security-tracker.debian.org/tracker/source-package/openjdk-7


-- 
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/51221dd1.9090...@thykier.net

Re: Bug#688772: [CTTE #688772] Dependency of meta-gnome on network-manager

[Niels Thykier]

On 2013-02-27 13:39, Michael Biebl wrote:
> On 27.02.2013 00:50, Chris Knadle wrote:
>> When this was brought up in the bug report, the response was 
>> "network-manager 
>> can be installed, then disabled", but how to do that wasn't documented 
>> anywhere in the network-manager package.  Instead the next suggestion was 
>> documenting this issue in the Wheey errata [2], but I don't see network-
>> manager or wicd mentioned there, nor mentioned in the Installation Guide [3] 
>> for Wheezy.
>>
>> Suggestions?
> 
> I will try to add a section to README.Debian which should be re-usable
> for the release notes / errata.
> 
> Neil, who should I contact getting those changes into the release notes?
> If anyone is willing to review the text, even better.
> 
> Michael
> 

File a bug against "release-notes" should work[1]

~Niels

[1]
http://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=release-notes;dist=unstable



-- 
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/512dffb7.8090...@thykier.net