Bug#1831: pgp-i bug..
Hi, Today I decided to configure pgp-i, and I came across 2 bugs. 1 is already listed as bug #1103, and is caused by a non excisting .pgp directory, and pgp doesn't create one, and so can't create it's output files. The other one isn't listed. When I run pgp -kg to generate a key, It ask me to choose 1, 2 or 3 or to type the number of bits. When I enter 2, It's says It will generate a 768 bit key, but when it is asking for random key presses, it only needs 4 random bits, which is 1 keypress. If I type 768 when asked the size of the key, It needs 248 random bits. So the number of bits isn't correctly set at 768 bits when you choose 2 (and maybe 1 and 3, haven't tested that). niels
Bug#3314: On request of Bruce: /etc/rc.boot/0serial way too optimistic
Package: base Version: boot disks of 1996_6_11 /etc/rc.boot/0serial tries to do a 'wild' interrupt detection. Also, it configures cua0 to cua32. That's "a bit optimistic"... Proposed fix: leave in only the last line of the script. Not two computers have the same COM ports: a Compaq Deskpro has only COM1, my computer has COM1 and COM2, other computers have internal modems on COM[34]. Niels -- Planet Internet Holding XXTP Support Engineer <[EMAIL PROTECTED]> I do not speak for my employer - they are perfectly able to do that.
Bug#3315: Bug in /etc/init.d/networks on 11-6 disks
Package: base Version: 1996_11_6 If you do not have a gateway on your system, the Debian installation puts 'GATEWAY=none' in /etc/init.d/networks. then later it tries to add a default route to that. Two possible solutions: (1) If no default gateway, just use the local hostname (2) If no default gateway, don't attempt to add a route to it. Niels -- Planet Internet Holding XXTP Support Engineer <[EMAIL PROTECTED]> I do not speak for my employer - they are perfectly able to do that.
Porter roll call for Debian Stretch
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi, Like last release, we are doing a roll call for porters of all release architectures. If you are an active porter behind one of the [release architectures] for the entire lifetime of Debian Stretch (est. end of 2020), please respond with a signed email containing the following before Friday, the 9th of September: * Which architectures are you committing to be an active porter for? * Please describe recent relevant porter contributions. * Are you running/using Debian testing or sid on said port(s)? * Are you testing/patching d-i for the port(s)? * If we were to enable -fPIE/-pie by default in GCC-6, should that change also apply to this port? [0] 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 Stretchj release (est. end of 2020): For , I - test (most|all) packages on this architecture - run a Debian testing or unstable system on port that I use regularly - fix toolchain issues - triage arch-specific bugs - fix arch-related bugs - triage d-i bugs - test d-i regularly - fix d-i bugs/issues - maintain buildds - maintain/provide hardware for (or assist with) automated tests on ci.d.n, jenkins.d.n (etc.) - run other automated tests outside the Debian QA services (Please describe these) - ... I believe the port ready to have -fPIE/-pie enabled by default. """ Niels, on behalf of the release team [0] Enabling -fPIE/-fpie by default would harden debian systems against certain attacks. See https://lintian.debian.org/tags/hardening-no-pie.html for more details. -BEGIN PGP SIGNATURE- iQIcBAEBCAAGBQJXtMMHAAoJEAVLu599gGRCArEP/j259ofvIXh0NE5uLqOtA8vu 4J84y6o15rHgg0iUGFwqAhk6GVtbvpxxqgH5vpj90UmUyIe55tHL7mf4NDjbEu9x w12DezTHpyGmmGSNNkQO6MV6FE0JeDjlSUlgBU27RamCQ7uKWCCNMMV48YZ/vtA0 4gj8KZtYxUNY5PEaCyV2WHXvU4sMuetnqZ4JfVDykCWlHV6yDCWMN/crar7XyWll iulUZFn9KlioVlSfQbkhrdJqwwbzXYaYee+GnD6rfVzPCIwpnVfKWoCYS8Zr0wub chmFx8EYAcBQ9OT5okfxZsN5J8kylX2CCDMEX5Ek6o7+4W76+L+V6F0hi1Npb2AH MFE5JLQLZGPs/3ilZSCz9io3u0vG78sLXPrQFbgJpa1E70W+bxohaieENPB0zGmS YBqF0BLM6XoySAURGMv8ohP3nT53PXtPDCU4EMF75bTvJa3QWJRSBC6uRtAY67tp h1bTWaE7Nmrtw9/mK+1oukjm8N7skvl1n0ZGQ+OmhfNcs8ii33fAV+u5zoGrywG5 0kXOfKfbt231/ManvsdGTHBd6Wodhprbo+Nw5tOA6B1R5jsSs0fvizKBRewrwiY7 66LNPtamSyqVapTBZqMEWaxvpfoWOgU8ZA1F9msD+qTHDd6OPCV692DAJbXlHfJe jof1hm/X+SyTZzungBvV =TKl5 -END PGP SIGNATURE-
Re: DD's, Debian Mentors needs you!
time contributor as putting a lot of effort into a package, having it be in good shape, and then never having it be sponsored simply because it didn’t get noticed. Soren Agreed; feedback latency is quite a de-motivation factor for me as well. P.S. Based on Phil’s work on Mentors and my interactions with him, I have advocated for him to become a Debian Developer, uploading. I think his contributions to Debian will be even more impactful when he can sponsor the packages he feels are ready. https://nm.debian.org/process/1305/ [...] Thanks for supporting Phil. :) Best regards, Niels
Re: Produce extra build artifacts during package builds
fying a broad enough pattern like '*', although this should be discouraged when building larger packages :-) This all sounds good to me. 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". But again, I sure we can figure out a solution to this problem in the practical coding - such as requiring the tool to copy it into the build tree first (which in turn requires the tool to ensure it is cleaned by `d/rules clean`, but presumably a trivially solvable problem). and sbuild (or pbuilder if you prefer) is responsible for enumerating files matching the given patterns and packing them into a tarball. I very much like this part of the design. They can delegate to a common tool to share the implementation without us worrying about build-depends contamination (which would be a issue for build-helpers). Since the logic would be able to run on the host system rather than in the chroot, we also do not have to worry about the installability being trashed in sid and temporarily neuter the log fetching ability. [...] Matthias Klose would like to find a way to do something that at the end of a build will look for and collect all the relevant files that are produced during an ICE (for example all the pre-processor inputs, etc). I'm not sure how to best solve it, but he was imagining a hook somewhere (in dpkg?) that would look for them and copy them into the directory. If we need an imperative hooks mechanism for something like this, then so be it, but I'd really prefer executing arbitrary code to be the uncommon case rather than something we always have to do. Perhaps dpkg or dh_auto_build could append appropriate patterns to my debian/extra-build-artifacts on build failure, so that this hook would just be acting as an extension to the declarative mechanism? smcv (not at Debconf) I am sure we can figure out a solution to this on top of the protocol. I see arguments for putting it in pbuilder/sbuild and for putting it into the build helper. I think this boils down to the use-case would be invoked in practice where exactly the logic goes. But I feel it is again a problem that is very solvable once we have the infrastructure in-place and a proper idea of how to play out the use-case. Dear, sbuild/pbuilder maintainers, feel free to give me a holler on this and lets fix this with a prototype somewhere. Best regards, Niels
Re: Produce extra build artifacts during package builds
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)
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
e automated end to end and that the tool is anchored somewhere to keep it maintained. Therefore, I am a bit skeptical on the ITR bug concept on the automation front, but I suppose it would have the advantage of "living off the land" for bug notifications. That is one of the complaints we have for the testing auto-remover. The ITR bug concept would also lower the barrier to agreeing to a "reassign the bug" rather than filing a new one. We could literally include the BTS instructions in the bug so you could just copy-paste and hit send. As long as this can be automated in practice (I am not an expert in automation involved the BTS), then the ITR bug concept has merit for me. A concrete proposal could be to give a warning one month before triggering the removal / filing the RM bug. In the timescale we are working with, I am not invested in whether that is 11 + 1 months or 12 + 1 months. What would be important is that you are guaranteed a minimum time to act on the warning. This can be relevant if our selection criteria or the dependency relation change and that should not lead to any immediate surprise removals[1]. It also acts as a safe-guard against bugs (there will always be another bug). Note: Requiring a warning first would also give all the packages on your list an automatic grace period. I would see that as an excellent way of testing the system and the process in practice to weed out "childhood diseases". :) My personal motivation for looking into this actually is the /usr-move work and the cross build support work. Please do consider me biased. Helmut [...] On the "Where do we anchor this"-front, where do you see this live long term? We have tons of QA tools that live and die with their interest of their creator. I appreciate your are quite a persistent individual even for Debian standards when it comes to archive-wide QA. However, eventually everyone gets hit by a proverbial bus. Organizationally, I think this would fit in the FTP master sphere of influence in the long term (not saying the prototyping must happen there), since they official decide the criteria for what is in the archive. This would also parallel the testing auto-remover living under the release team. I know I said the FTP master team was resource constrained and that is part of why I would say the prototype would happen outside the team. But since they are in the receiving end of these RM bugs, it also makes sense they have authority and is empowered to fix the tooling if it is sub-optimal for them in the long run. Nevertheless, it would not be a blocker for me that the long term maintenance strategy for this tool would be unclear when we implement it. But I feel we should start that discussion, so we are clear on it and also who is the authoritative source for future changes. In my book, debian-devel consensus gathering is slow and can be quite draining, so we should not use it for "day-to-day" operational matters. To me, that implies having a team with authority to manage that. Leveraging a delegated team would checks some boxes for me on that front, but it is certainly not a necessity. Best regards, Niels PS: As much as I want automation, I do not mind the prototype starting as a semi-automatic process if that is what it takes to get started. [1]: A concrete example could be that a package with a 2-year old RC bug was kept around because it had a reverse dependency and we start with "no automatic reverse dependency removal". If that reverse dependency was updated to drop that dependency then the RC buggy package should get its warning and a grace timer of one month (in my proposal) rather than immediately getting removed.
Re: DEP5 and spdx shortname of license
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: For those who care about stable updates
On Thursday 09 March 2006 11:32, Martin Schulze wrote: > I'm sorry to announce this but you'll have to find a new person who works > on updating Debian stable and who is willing to cope with black holes and > ftpmasters. > James Troup as ftpmaster rejected my recent request to become an.. Then one suggest mentioned Mr. James Troup to take over, and do your job, which I personally find have been VERY WELL DONE - THANKS :-) Very sad to hear about such an announcement. I am just an old pensioner, end user, using debian stable happily. :-( -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bits from the DPL: Freedom and etch hik :-) At skimme, ny mail
On Monday 28 August 2006 20:35, Anthony Towns wrote: > Hello, world! > > As a project, Debian is heavily committed to the ideals of free software. > That's not news to anyone reading this, I'm sure, as it's something > we've constantly worked to improve, whether that be by establishing our > Social Contract and the Debian Free Software Guidelines or by working > with other organisations such as Software in the Public Interest [0], > the Free Software Foundation [1], the Open Source Institute [2], or > Creative Commons [3] to further promote those ideals. > > Another two major steps we have made towards the ideal of software > freedom over the course of the project has been removing the need to run > non-free software to contribute to Debian -- made possible by Werner > Koch's development of the GNU Privacy Guard (gnupg/gpg); and removing > the need to run non-free software on our own servers, which was completed > in May 2000 when we switched from qmail to postfix and exim for handling > debian.org email [4]. > > The most recent efforts in relation to this ongoing goal have been in > paying increased attention to the freedoms provided for works other than > regular applications and libraries -- most notably documentation [5]. > > I believe the current expectation is that there will be absolutely > no problems ensuring that the Debian System will not only be composed > entirely of free applications and libraries, as it has for years, but > also of free documentation, free graphics, free videos, free fonts, > and free drivers. > > At this point, there seem to be only three areas where we won't easily be > able to meet the goal of everything in the Debian System meeting the DFSG: > > (a) License texts only rarely explicitly allow other authors to create > new, derivative licenses based on existing ones -- you either > use what's there, or get your own lawyer to draft something in > their own words. > > (b) We generally aren't able to consider distributing truly large > "source" files, including losslessly encoded video, geographical > data sets, or the complete design specification for some fonts. > > (c) A number of drivers in the Linux kernel include firmware to be > uploaded to the chipsets they support that is provided as > either a sequence of hex codes, or as a separate binary file -- > while modifying the code is allowed, in many if not most or all > such cases, the firmware is effectively being provided without > useful source. > > License texts themselves are not an easy issue to resolve, but this is > somewhat balanced out by that generally not being necessary -- and indeed > while we do encourage people to come up with modifications to software > they use, coming up with new and modified licenses is often a much worse > idea than reusing an existing free license, even if it has flaws. > > Large source files and how we should deal with them have been an > unresolved concern for a long time -- Bug#38902 might give you some idea > just how long. Up until now we've dealt with it by simply packaging the > source in the form that we need it -- for which a reduced or compressed > form almost always suffices. It will probably be some time yet before > we can come up with a sensible technical approach here that balances out > the bandwidth and storage usage appropriately. > > Firmware, however, is a much more immediately resolvable issue -- and > one that has already progressed signficantly over the past few years > as Linux's interface for loadable firmware has improved, and hardware > manufacturers gradually become more comfortable with releasing free > drivers and free firmware. > > The major problem remaining for Debian in handling that, is that we > don't have a good way of supporting installs on hardware that needs > firmware that we don't have source for and have separated into the > non-free component. Joey Hess summarised the problems in dealing with > that to the -vote list [6] and estimated six months of work developing > the appropriate support in the installer, with presumably more time > needed after that for testing and quality assurance. > > So the question is what should we do here? One approach would be to say > "we're committed to making the Debian System completely free, so until > that's done, we're not ready to release". Another is to say "we've made a > lot of improvements since sarge, on this score and others, so let's get > etch out now, and move onto the next bit after that". A third is to say > "we've committed to getting etch out, and to making it be completely > free -- if that means not supporting a range of hardware, so be it". > > One way or another we're going to have to make a decision on what > approach to take fairly soon -- and general resolutions on how to square > up the approach we take are already being discussed on the debian-vote > list. Personally, I'd appreciate knowing wh
Re: Automatic ITP closing.
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)
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.
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.
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
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
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
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?
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
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
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
-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
-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
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.
-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
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?
-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
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
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
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
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)
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!
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
-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?
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?
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
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
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
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
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)
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 zo
Re: How should we do for font-adobe-copyrighted-fragment error?
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
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)
-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]:
Re: Candidates for removal from testing (2013-06-30)
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)
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]
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]
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
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 > (<http://bugs.debian.org/701081>), > 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
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
-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?
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
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)
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
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
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
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
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)
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
First autoremovals happen in about 8 days
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:
Re: First autoremovals happen in about 8 days
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
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)
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)
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)
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
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)
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)
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
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))
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
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
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))
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))
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
-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
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
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
-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
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
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
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
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
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
-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
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
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
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?
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?
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
-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
Re: Candidates for removal from testing
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)
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)
-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)
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)
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)
-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)
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)
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)
-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
