Bug#846002: blends-tasks must not be priority:important (was Re: Bug#846002: Lowering severity)
> "Ole" == Ole Streicher writes: Ole> We already have more that 5700 popcon-counted installations Ole> with the blends selection in the installer. This should give Ole> some base for that. Hi. Speaking with my TC hat on. I don't find quoting popcon stats useful. You've used them to support the claim both that this is important and that users don't find it confusing. I understand your reasoning for why you believe that the popcon stats argue this is not confusing. I think your reasoning rests of the false assumptions that users are likely to report bugs when they find something confusing. In my experience that's not the case. Instead, they are likely to get grumpy and decrease their overall confidence in some software. Users cannot be counted on to proactively report confusing aspects of software. I find the claim that this is important because of the popcon numbers vaguely dubious as well, but it's harder to justify my concern. At least for me though, every time you quote popcon numbers, I take you less seriously.
Bug#846002: blends-tasks must not be priority:important - ballot proposal
Is our intent to override the maintainer or provide advice? I don't care what the answer is but perhaps we want to be clear. I'm fine with this ballot beyond that. Perhaps we want to override the blends-tasks maintainers to the extent that they disagree with the tasksel maintainers?
Bug#842497: krb5: [INTL:de] German translation is missing
I'm aware of no issue. I'll look into it; will be packaging 1.15~beta1 soon, and this is almost certainly a packaging error, not an intentional change. Or rather, I'm sure the change is not intended; it's alomst certainly just that the file somehow got dropped.
Bug#827061: Please commit to OpenSSL 1.0.2 in stretch now not constantly re-evaluateing
My understanding of the current plan is that we're adding openssl 1.1.0 to unstable, but will make a decision about whether to drop libssl1.0.2 later. That's really frustrating for the rest of the ecosystem--our users and our upstreams, and I'd ask the release team to commit now to 1.0.2 being available for stretch. At least one of the clusters of packages I'm involved in--shibboleth and moonshot will require some real upstream porting effort. That's under way in a time scale that will work for buster, but is very unlikely to meet the stretch freeze timeline. It's possible that resources could be reprioritized and that with a fairly agressive scramble, we could get things working with OpenSSL 1.1 in time for stretch. However money and time are finite. That would take away from other priorities and would have significant risks in terms of stability. Debian matters in the larger ecosystems, and we owe it to our upstreams and our users to decide now whether we're asking people to make those sort of mad scrambles. I think we should not. Regardless, decisions now matter. Thanks for your consideration, --Sam
Bug#828440: moonshot-gss-eap: FTBFS with openssl 1.1.0
> "Sebastian" == Sebastian Andrzej Siewior writes: Sebastian> control: tags -1 patch Sebastian> On 2016-06-26 12:23:04 [+0200], Kurt Roeckx wrote: >> OpenSSL 1.1.0 is about to released. During a rebuild of all >> packages using OpenSSL this package fail to build. A log of that >> build can be found at: >> https://breakpoint.cc/openssl-1.1-rebuild-2016-05-29/Attempted/moonshot-gss-eap_0.9.5-1_amd64-20160529-1451 Sebastian> this builds now. Do you have anything to verify? Hi. I'm sorry I didn't get a chance to respond to your other mail. upstream has dealt with moonshot-gss-eap and moonshot-ui and I plan to address the bugs there with a new upstream version. We'll probably need to build-dep on libssl1.0 until the entire cluster builds with 1.1; I think having two related libraries in the same address space use different versions of ssl will be problematic.
Bug#827061: Please commit to OpenSSL 1.0.2 in stretch now not constantly re-evaluateing
>>>>> "Sebastian" == Sebastian Andrzej Siewior writes: Sebastian> On 2016-10-31 11:16:38 [-0400], Sam Hartman wrote: >> At least one of the clusters of packages I'm involved >> in--shibboleth and moonshot will require some real upstream >> porting effort. That's under way in a time scale that will work >> for buster, but is very unlikely to meet the stretch freeze >> timeline. Sebastian> Do you want me to look into moonshot-gss-eap? The other Sebastian> moonshot-* package with the RC bug won't be part of Sebastian> current testing. I didn't find anything that matches Sebastian> shibboleth. Hi. I'm really sorry I didn't get a chance to respond earlier. I was traveling. Shibboleth comprises opensaml, xmltooling, heavily depends on xml-security-c and shibboleth-sp2. Ferenc Wágner (copied) has been handling the Shibboleth packaging and has an understanding of where the upstream efforts are. There's been discussion on pkg-shibboleth-...@lists.alioth.debian.org. The area that I tdon't think anyone has examined in the moonshot cluster is libradsec, which also depends on libevent fairly heavily.
Bug#842497: krb5: [INTL:de] German translation is missing
> "Chris" == Chris Leick writes: Chris> Package: krb5 Version: 1.14.3+dfsg Severity: minor Tags: l10n Chris> Hi, Chris> I've seen, that the German translation isn't included in Chris> version 1.14.3. Is there an issue with the translated file? Chris> Please let me know, if I can help. The translation was sent Chris> with Bug 816548. Hi. As best I can tell we're shipping src/po/de.po in our builds. Is it possiblee that the issue is we're shipping the German translations but not using them? I am testing a fix if that's the case.
Bug#843209: Please permit class directory-like feature for fai-diskimage
package: fai version: 5.2 severity: wishlist. FAI has a great feature in the class directory that allows a configuration space to infer classes from things such as the installed hardware. This is not currently available from fai-diskimage. I'd really like to have a feature like that for fai-diskimage. My recommendation is that the class script be run for fai-diskimage, and that there be some way for a script to determine if it is producing a diskimage so that scripts that do things like output classes based on the current machine would not run. An alternative would be to have a directory parallel to class that was only used for diskimage. A far less desirable alternative would be for the cloud team to wrap fai-diskimage for this purpose. We'll almost certainly wrap fai-diskimage, but I was hoping that our wrappers would focus on things like uploading images, not on stuff like this. You said you didn't see the point for disk-images. You don't infer things from the current environment, but you infer aspects of configuration from other aspects of configuration to improve maintainability, and simplicity of calling the interface. Here are examples where this is useful. * inferring either GRUB_PC or GRUB_EFI from AMD64 and whether the provider in question currently uses EFI * Any of GCE or EC2 implying CLOUD * Implying classes from release. For example, as we moved from wheezy to jessie, SYSTEMD might be implied. It seems likely that there will be similar future-such that will be triggered either by Debian release, or by the time frame and provider For non-cloud work, I think I'll want this feature in my own fai-diskimage usage. Inside my employer, Hadron, we'll have a number of classes related to things like whether a desktop is installed, whether we're building an installer image, or an image to be given to hardware vendors to be burned into systems before they are delivered to us. Only a couple of these configurations will be supported at any given time, but to ease comprehension of the configuration space and to deal with code evolution, these will be split into classes. I'd prefer that people calling fai-diskimage provide in one top-level class corresponding to one of the supported top-level configurations. --Sam I'm happy to work on an implementation once you figure out what approaches you'd be willing to accept.
Bug#845256: raid5 metadata, discards and other issues
package: lvm2 version: 2.02.167-1 This bug is opened to document some problems discovered in an IRC conversation on #debian-devel between Sam Hartman and Bastian Blank The problem seemed to be that often (although not in all the time in Sam's experience) lvcreate --type raid5 -L 128g -n volumename vgname produced a volume with a bogus raid metadata bitmap. In particular, lvchange -an volumename&&lvchange -ay volumename would fail with errno -22 trying to read the bitmap Looking at the _rmeta_0 volumes, the bitmap looked like garbage; among other things the BITM magic number was absent. Doing something like dd if=/dev/zero of=/dev/mapper/vgname-volumename_rmeta_0 (through n for each rmeta volume) would permit the volume to be activated one more time. Thes volumes failed to activate with linux 4.8.0-1-amd64 at all, claiming an unknown feature flag. However, at least in Sam's experience, zeroing all the metadata and activating the volume gets good metadata written out including a good bitmap on 4.8.0-1-amd64 Bastian was unable to produce a raid5 logical volume at all on 4.8.0-1-amd64. Sam's theory was that lvcreate does not properly zero the metadata volume on create, and that since the segment allocation is predictable, Bastian's system was reusing the same metadata extents after an upgrade from 4.7 to 4.8. Sam is able to create raid5 volumes on 45.8.0-1-amd64. However, as part of this process, Sam discovered that even with issue_discards set to 1, lvremove does not issue discards for the data segments of a raid5 volume. To test do something like # create volume dd if=/etc/motd bs=1024k seek=1 dd if=/dev/vgname/volumename bs=1024k skip=1 |less #to confirm motd lvremove vgname/volumename #immediately recreate volume with same params dd if=/dev/vgname/volumename bs=1024k skip=1 |less #to confirm motd the 4.7 issues can probably be ignored since it is an old kernel we never shipped. I think that the failing to zero metadata and failing to discard are important to investigate.
Bug#846088: Alladin License in krb5
Hmm. So, first, the file refers to a modified copy of the Alladin free public license, from a kit for implementing filesystems. I'm kind of boggled that someone would start from the Alladin license, but since I have no idea what modifications they made, I have no idea whether it's free. However the author of the software in question was working for the part of MIT responsible for Kerberos around that period of time. I suspect this is a simple case of someone cut&pasting their work from one project to another and failing to fix up the license header. MIT is fairly good about getting copyright assignments so this can probably be cleared up. --Sam
Bug#846088: Info received (Bug#846088: Alladin License in krb5)
To be clear I've contacted upstream off-list and we'll see what we find in the next few days.
Bug#841294: Overrule maitainer of "global" to package a new upstream version
> "Ron" == Ron writes: Ron> Hi OdyX, Ron> On Wed, Nov 16, 2016 at 03:23:47PM +0100, Didier 'OdyX' Raboud wrote: >> Hi there, >> >> I've been mostly VAC, and only now found enough time to properly >> read through this bug log. In the interest of transparency and to >> help the TC reach a consensus (also through understanding what >> the other members' understanding, ideas and positions are), here >> comes my current understanding of the problem at hand. >> >> As preamble, I will upfront state that I have _not_ looked in the >> precise details of the so-called 'htags' functionality, as, the >> rest will show, my current viewpoint on the problem is that it >> doesn't matter. Ron> If we run with your proposal, what are you actually suggesting Ron> we tell the people who'd be upset by the loss of htags without Ron> notice in Stretch? Because I don't really see how you've Ron> addressed that here. Ron, thanks for working with the process. I think that one thing you sometimes find when you try and build consensus is that your conception of the problem and even the values by which a solution should be judged is not shared. As I understand it, you believe we should be evaluating the technical options and that preserving things that work is of high value. I think a lot of us believe that get newest code is a presumptive value especially over the multiple releases time frame. That is, I disagree with you that I need to address the question of htags and figure out whether htags users are being impacted. That might have been true for one release. But over a longer time frame, the really strong presumption is that we prefer a version that is being actively developed to one that isn't. That if people won't step forward and maintain htags, it goes awy. That's a presumption. If someone gets evidence that htags is heavily used, we can consider that. We might even go so far given sufficient evidence to decide that forking global and never taking a new upstream was the right answer for our users. That would take a lot of evidence. I disagree with your approach that the people wanting to remove htags need to show that it is being used. I disagree with your view that over the timescales involved, people wanting a new upstream need to justify that. Yes, removing htags creates a regression. Yes, I'm effectively saying "If you're using htags, sucks to be you. If you're willing to spend effort maintaining a version of htags that is secure, then we might be able to bring it back. Yes, it's possible that we'll learn we broke things and need to revert. But I think what you're getting here from a lot of people is a belief that our community norm strongly favors active development and new software. And sometimes when features are effectively not maintained in a manner that we can package them, they go away. I don't think it's reasonable to defer this to upstream and wait until upstream removes htags. I have tried to understand the technical issues. I'm not sure I'm 100% in agreement in your analysis there, but I'm fairly close. However, I haven't found the technical issues tend to affect my analysis of what Debian should do. I'd strongly urge you to work on a global6 package. I don't care whether it's called global or global6. I don't think it should include insecure cgi scripts that are enabled by default. I'd be fine if it didn't include htags at all. I'm not saying upload that package now; I'm not saying where to upload it. (Although I wouldn't object to an upload to experimental or unstable) I think having that package ready and keeping options open as long as possible would help preserve our ability to work through this process. I hope that would go a long way to addressing people's feelings of frustration. Thanks for your consideration, --Sam
Bug#841294: Global Ballot Thoughts
I'd really like to see the TC offer at least the following advice: 1) We believe that strong evidence is required to hold back integrating new versions of software like global. The burden of proof is on those who propose not to update, not on those who would like Debian to contain current upstream features. 2) This burden has not been met with regard to htags and regressions related to htags. 3) Delays in discussion of this issue over the year suggest that having more people involved in maintaining the global package would help address a perception that the maintainer is blocking forward progress. I don't think I'd support giving global to someone else. I don't think we even need to say "Ron you did something bad." I do think that Ron contributed to a harmful perception that damages those who would use and contribute to global in Debian. I think taking steps like involning others in the process would be good in fighting that perception and would be good for the package at a technical level. If we can find a path forward that gets a new global into Debian, I'd be happy only offering advice. If we get stuck doing that, I think we need to overrule something.
Bug#841294: Global Ballot Thoughts
Like you I want to see global6 for stretch. I'm not sure I want to see it bad enough to override someone. I'd rank doing so above FD though but below a pure advice option.
Bug#841294: Global Ballot Thoughts
>>>>> "Ian" == Ian Jackson writes:
Ian> Sam Hartman writes ("Bug#841294: Global Ballot Thoughts"):
>> Like you I want to see global6 for stretch. I'm not sure I want
>> to see it bad enough to override someone. I'd rank doing so
>> above FD though but below a pure advice option.
Ian> Why are you prepared to override[0]
I am not prepared to override those seeking global6 either.
Ian> but not prepared to override
Ian> Ron Lee
Because in this instance I believe giving advice is going to be
sufficient to get action.
If some reasonable version of global6 doesn't happen post haste, I could
change my mind in the order of a week or two.
Ian> Have you been reading debian-project ?
No.
Bug#841294: Global Ballot Thoughts
> "Ian" == Ian Jackson writes: Ian> I know that you do not _set out_ reinforce Ron's position of Ian> power over his victims. That is not your goal. You are trying Ian> to come to an amicable settlement. You are trying to get Ian> everyone to be nice. Ian> But when people are being oppressed, it is quite wrong to make Ian> the feelings of the perpetrator a primary consideration. First Ian> help the victims, by relieving them from the grasp of their Ian> oppressor. I disagree with the idea that this situation is about an aggressor and victims. I agree such situations exist. I do not think this situation currently is such a situation. That is key to my position. I do not think engaging furthure on this point will serve this discussion.
Bug#841294: Global Ballot Thoughts
So, does someone want to propose a resolution so we can move this forward?
Bug#842497: [INTL:de] German translation is missing again
> "Chris" == Chris Leick writes: Chris> Hi, Chris> It seams, that the German translation isn't included in Chris> version 1.15-1. Is there an issue with the translated file? Chris> Please let me know, if I can help. The You filed a substantially similar bug on the previous version and never replied to my question there. Why does it look to you like the German translation is not included? As best I can tell it is being included.
Bug#844263: libxml-security-c-dev: depending on libssl1.0-dev breaks open-vm-tools
So, can we (Debian) support SSL 1.1 with Shibboleth? That is, are the patches something you're comfortable integrating as Debian?
Bug#846002: blends-tasks must not be priority:important (was Re: Bug#846002: Lowering severity)
So, what impact does having blends-tasks have besides wasting disk space. It adds tasks to the installer menu. Are those tasks we want on all system installs or not? If this is purely about disk space, I think it's less of an issue than if it provides a bad user experience.
Bug#846002: blends-tasks must not be priority:important (was Re: Bug#846002: Lowering severity)
For what it's worth, I think the policy question here is not a significant one. Holger is right that we should either fix policy or fix both (tasksel-data and blends-tasks). I think that is a bug that should get hashed out. I don't think it is all that timely, and I don't think it matters much how we handle things. It seems clear that if we want the data available for tasksel, then when tasksel runs, both tasksel-data and blends-tasks need to be installed. How to align policy and implementation is something we should eventually figure out. I think the far more important question is whether the presentation of blends is what our users need.
Bug#850834: dpkg --unpack produces zero-byte file, but dpkg -x works
package: dpkg version: 1.18.10 Hi. For a non-debian archive, I've been packaging up some disk images into debian packages, because we tend to use debs for software distribution. It's not working very well. When I run dpkg -x hadron-installer-efi_0.10_all.deb /tmp/foo, I get root@mini-buildd:/tmp# ls -l /tmp/foo/usr/share/hadron-installer/ total 8388608 -rw-r--r-- 1 root root 8589934592 Jan 10 09:52 installer-efi.raw But when I run dpkg -I I get less promising results. root@mini-buildd:/tmp# dpkg -i /tmp/hadron-installer-efi_0.10_all.deb Selecting previously unselected package hadron-installer-efi. (Reading database ... 155174 files and directories currently installed.) Preparing to unpack .../hadron-installer-efi_0.10_all.deb ... Unpacking hadron-installer-efi (0.10) ... Setting up hadron-installer-efi (0.10) ... root@mini-buildd:/tmp# ls -l /usr/share/hadron-installer total 0 -rw-r--r-- 1 root root 0 Jan 10 09:52 installer-efi.raw The only interesting note from the build is that I'm using gzip to compress the deb. We find that the default compression is unacceptably slow, and gzip does well enough for our needs. Here's the part of the buildlog. dh_md5sums debian/rules override_dh_builddeb make[1]: Entering directory '/<>' dh_builddeb -- -Zgzip dpkg-deb: building package 'hadron-installer-efi' in '../hadron-installer-efi_0.10_all.deb'. dpkg-deb: building package 'hadron-installer-legacy' in '../hadron-installer-legacy_0.10_all.deb'. make[1]: Leaving directory '/<>' dpkg-genchanges --build=any,all >../hadron-installer-images_0.10_amd64.changes dpkg-genchanges: info: binary-only upload (no source code included) dpkg-source --after-build hadron-installer-images-0.10 dpkg-buildpackage: info: binary-only upload (no source included) Build finished at 2017-01-10T15:24:59Z While this is not something we're releasing, there's no significant proprietary interest. I'd be happy to give you access to the resulting deb, more of the build log, whatever is necessary. The deb is over 2g in size, but I'm happy to make it available. For debian developers, I've placed a URI to the deb in master.debian.org:~hartmans/dpkg-bug-url I would prefer that URI not be posted in public simply to avoid exposing our infrastructure. Again, I'm happy to assist in any way I can and would appreciate any help you can provide.
Bug#850887: Decide proper solution for binutils' mips* bug
Hi. I'd really appreciate comments from debian-release on this issue. Would debian-release like us to take this up? If so, I have a proposal for how to fast-track this situation, but I am only comfortable doing that if the release team is involved.
Bug#850887: TC Involvement: MIPS and binutils
Hi. As you are probably aware, the question of what to do about linking on mips and stretch has been referred to the TC. There's a reasonable probability that we're going to want to move very quickly on this issue, and I wanted to reach out to you and see how we could best work with you to collect your input. I'd be happy to set up an IRC discussion, to set up a phone call, etc. I think that might work better than an email discussion, because the email discussion might involve a number of round trips. I'd be happy to work one-on-one and summarize results/provide logs back to the entire TC, or to set up something open to as many people as we can. Also if there's a TC member you'd rather work with than me, I'm sure we'd be happy to facilitate this. I'm hoping that you will be able to quickly work with us to understand this issue and your position. Thanks for your consideration, --Sam
Bug#850887: TC Involvement: MIPS and binutils
>>>>> "Lisandro" == Lisandro Damián Nicanor Pérez Meyer >>>>> writes: Lisandro> On miércoles, 11 de enero de 2017 09:39:25 ART Sam Hartman wrote: >> Hi. >> >> As you are probably aware, the question of what to do about >> linking on mips and stretch has been referred to the TC. There's >> a reasonable probability that we're going to want to move very >> quickly on this issue, and I wanted to reach out to you and see >> how we could best work with you to collect your input. >> >> I'd be happy to set up an IRC discussion, to set up a phone call, >> etc. I think that might work better than an email discussion, >> because the email discussion might involve a number of round >> trips. I'd be happy to work one-on-one and summarize >> results/provide logs back to the entire TC, or to set up >> something open to as many people as we can. Also if there's a TC >> member you'd rather work with than me, I'm sure we'd be happy to >> facilitate this. >> >> I'm hoping that you will be able to quickly work with us to >> understand this issue and your position. Lisandro> Hi Sam! I think an IRC discussion will be the best choice Lisandro> here as my phone lines are really not reliable at all :-( Lisandro> I'll be online from 17:30 UTC onwards, nick lisandro on Lisandro> freenode. that was to doko not you. I'd be happy to chat, but you've articulated your position fairly well. If there's stuff not in the bug you'd like me to know about I'd be happy to set things up, but from the bug logs, your position seems fairly simple. Let's see if my summary is accurate: * This bug is creating a number of ftbfses, particularly for larger//more complex libraries on mips. * You have a preferred minimal work-around you tried to upload * Doko requested you not upload something until it was patched upstream. * You want a solution sooner than that. Is that approximately correct?
Bug#850967: Clarify /usr/bin/foo should not be hardcoded even in upstream parts
I'll note that the practice of hard-coding paths is fairly common. One common cause for this is programs that don't want to rely on PATH for calling exec. Systemd is a particularly interesting example. ExecStart and related arguments in systemd units are required to include full paths. I am very uncomfortable with the idea of setting policy here. I find I tend to agree with Daniel's position a bit more than Ian's. In particular, I definitely think that for closely-related versions of software, making sure the same versions are used is helpful. I've hurt myself more by having parts of something built in /usr/local than I have not being able to override things for debugging. However, I think that both parties have valid points. So, I'd be much more comfortable if we wanted to help make people more aware of the tradeoffs than I would setting policy.
Bug#850887: [TIMELY for TC members] Interim Ballot Proposal: #850887 binutils mips
I heard back from doko today. We can expect a reply tomorrow. We also talked briefly about the issue. Realistically, i cannot imagine the TC coming to any final decision on something like this in under three weeks. That timeline seems fairly aggressive actually. However, I think the TC could act much more quickly in an interim capacity. I personally believe that having packages building is a better interim state than the status quo. There are risks to an interim measure. We could have packages in the archive that build but fail to function correctly. Depending on what we do long term, we could end up replacing packges currently in Stretch with packages we can no longer rebuild. I personally think that when I weigh those risks against my estimate of their probability, I think it makes sense to adopt an interim measure. Roughly I propose to override the maintainer and permit an NMU to be made for this issue. The decision stands until the maintainer fixes the bug or Stretch releases, or another resolution is passed (presumably with a more permanent decision). Yes, that means that the maintainer could reintroduce the bug and revert the NMU immediately on the release of Stretch. First, I hope even the TC can act quickly enough that we're not using an interim measure then. Second, I think that's actually appropriate. The justification for an interim measure is the impending freeze. Once we get Stretch out, this issue is still important, TC involvement may be necessary, but there is no reason to cut process corners. I propose to be very agressive in calling for a vote on the following ballot. I plan to call for a vote in 24 hours if I get support from at least one TC member and no objections from within the TC or release team. In that assumption is a belief that I'll have a chance to review the patch and the upstream bugzilla discussion prior to calling for a vote. If I don't have time to do that, I will delay, although I would not object to someone else who has done the review calling for a vote. Also, within that time, we should hear from doko. His input may change my thinking even for an interim measure. I want to stress this is only my interim thinking. This is in the TC git; feel free to fix/amend as necessary. In #850887, the Debian Technical Committee was asked to choose a solution for #840227, a bug that prevents a significant number of packages from building on the mips architecture. Given the upcoming Stretch freeze, this issue is urgent. As an interim measure, using its powers under section 6.1.4 of the Debian Constitution, the Technical Committee overrules Matthias Klose's decision to revert the NMU of binutils fixing #840227. The committee requests Lisandro Damián Nicanor Pérez Meyer to make a new NMU fixing #840227. The committee requests the release team to support the interim nature of this solution and if a permanent solution is adopted before the release of Stretch, to consider including that solution in Stretch even if the freeze criteria would not normally permit such consideration. In addition, the committee requests the stable release managers for Stretch to consider including the eventual upstream solution for this issue into a stretch update. This interim decision stands until the release of Stretch, until it is replaced by resolution, or until the binutils maintainer fixes #840227 in some other manner. Choice 1: Approve the Resolution (3:1 majority) Choice 2: Reject this Interim Measure Choice 3: Further Discussion I've included a separate reject and FD choice to distinguish "we need more info for deciding on an interm solution even" from "we have enough info and this approach is bad." signature.asc Description: PGP signature
Bug#850887: [TIMELY for TC members] Interim Ballot Proposal: #850887 binutils mips
> "Ian" == Ian Jackson writes: Ian> You should explicitly state whether you want this NMU to be Ian> DELAYED. Good point. I think we don't want a delay. Updated the ballot in git.
Bug#850887: Decide proper solution for binutils' mips* bug
As a FYI, Matthias wrote to me in IRC just now indicating that he plans to upload a patch in the next couple of days. (He needs to get to the location where he has the right environment before preparing the upload). As such, I'm planning on holding off on calling for any votes.
Bug#850967: Clarify /usr/bin/foo should not be hardcoded even in upstream parts
> "Josh" == Josh Triplett writes: Josh> As another technical alternative, which I haven't seen Josh> mentioned elsewhere in this thread or related bug reports: Josh> when I need to override a packaged binary or file temporarily Josh> for debugging purposes, without forgetting to restore it Josh> later, I tend to use "mount --bind /my/replacement Josh> /usr/bin/foo". For instance, for local testing while Josh> developing dh-cargo, which required a newer version of Cargo Josh> than packaged in Debian at the time, I built a local version Josh> of Cargo and did "mount --bind ~/src/cargo/target/debug/cargo Josh> /usr/bin/cargo". That allowed me to easily test-build Josh> packages before the availability of a Debian package of a Josh> sufficiently new Cargo. O, cool, that's really need. And as a throw-back to an alternate Plan9 history, you could presumably unshare your mount namespace and even do that for a subset of the processes on a system, getting almost all the benefits of PATH.
Bug#850967: Why did you want us to keep this open?
Dear Matthias: Hi. As I understand our IRC conversation, you asked me to keep the TC bug regarding mips binutils open even after your upload. First, I want to confirm that understanding. Second, what are you hoping for from the TC at this point? I think you've resolved the issue that came to us, and absent your request I'd normally close this bug. We're happy to help, but would appreciate guidance on how we could be of assistance. --Sam
Bug#850887: To the right bug this time: Why do you want us to keep this open?
I posted this to the wrong bug, now reposting: Dear Matthias: Hi. As I understand our IRC conversation, you asked me to keep the TC bug regarding mips binutils open even after your upload. First, I want to confirm that understanding. Second, what are you hoping for from the TC at this point? I think you've resolved the issue that came to us, and absent your request I'd normally close this bug. We're happy to help, but would appreciate guidance on how we could be of assistance. --Sam
Bug#839570: Browserified javascript and DFSG 2 (reopening)
Obviously, there's a level at which I agree with you. When this came around last time, I wanted us to issue advice. The advice I wanted to issue isn't the advice you wished we issued, but it would have at least been advice. However, I was the only one on the TC who wanted to touch the issue. It was quite clear from the IRC meeting that I didn't have the support. I think the TC did reach a consensus not to touch the general question and give advice there. I think it's clear that the TC believes that this package is not DFSG free. I think it's clear that the TC believes perl would be better if the situation was improved. I thought it was clear we believed perl had a DFSG issue, although IRC discussion today makes that less clear. I don't think the value of having the TC formally say any of those specific things is very high. I don't think having a formal vote to confirm the TC consensus to say nothing does much good. I do think such an outcome would accurately represent the current thinking of the TC as a body. I haven't seen anyone who has reviewed the log claim otherwise. I also don't think asking for a formal vote in a situation where there is a clear consensus is the right way to ask someone to change their mind. I think the TC is making the wrong call here. So do you. I guess I don't mind that you're bringing that up again. I'll be delighted if it changes peoples' minds. I don't entirely know what I'm saying. Perhaps just expressing disappointment in this overall process. --Sam
Bug#839570: Browserified javascript and DFSG 2 (reopening)
>>>>> "Sam" == Sam Hartman writes: Sam> Obviously, there's a level at which I agree with you. When Sam> this came around last time, I wanted us to issue advice. This was something I intended to send to Ian privately, not to the bug. Apologies for the spam and for emphasis that probably doesn't help the public discussion.
Bug#836154: sbuild --no-arch-any --no-arch-all --source fails on all only dsc
> "Johannes" == Johannes Schauer writes: Johannes> Do you know a situation when it would be beneficial to let Johannes> sbuild create the source package *again* after it has Johannes> already been produced for sbuild? Sbuild can take a directory as input. I tend to use it in that way for CI-driven builds from git repositories. Sometimes I want source uploads, sometimes I want a binary upload. (In this case I ended up wanting a source upload because of another bug in mini-buildd, although in other cases I'd just want a source upload). As an example, I might want to run gbp buildpackage --git-export-dir=somewhere --git-builder=sbuild --source --no-arch-any --no-arch-all to prepare an upload to debian (after testing my tree some other way). Does sbuild add that much in that situation? No, but it sure doesn't hurt, and consistency is nice.
Bug#806617: freeradius: FTBFS when built with dpkg-buildpackage -A (dh_install: freeradius-common missing files)
> "Raphael" == Raphael Hertzog writes: Raphael> On Thu, 14 Jul 2016 22:09:52 + Santiago Vila wrote: >> I have the ok from the Release Managers to consider this issue as >> RC for stretch. I'm going to wait at least one week before >> raising this to "serious". Raphael> So nobody fixed this issue and freeradius is now gone from Raphael> testing :-( In my opinion freeradius 2.x is better gone from Debian. In my previous job I was willing to put in the effort to maintain freeradius 3.x if some other developer was willing to put together debian/copyright and do the DFSG audit. That never happened, although someone did 90% of the work and went silent. Unfortunately, my new job doesn't involve FreeRADIUS at all. I think requesting removal of freeradius 2.x would be preferable to orphaning it.
Bug#806617: freeradius: FTBFS when built with dpkg-buildpackage -A (dh_install: freeradius-common missing files)
> "Josip" == Josip Rodin writes: Josip> On Tue, Aug 30, 2016 at 11:20:50AM +0200, Raphael Hertzog wrote: >> Josip, do you really still care about this package? Josip> I'm pretty sure I told Sam to take it over a few years Josip> back...? O, if that's what you were trying to say, that is very different from what I heard. Regardless, I have move on from the job that had a lot of dependence on FreeRadius, and can't give it attention either. --Sam
Bug#806617: freeradius: FTBFS when built with dpkg-buildpackage -A (dh_install: freeradius-common missing files)
> "Raphael" == Raphael Hertzog writes: Raphael> It would seem natural to orphan it and to let the new Raphael> maintainer deal with updating it to version 3.x. I think 3.x is likely to be new packaging and entirely breaks compatibility with the 2.x config. If we orphan 2.x someone might fix the RC bug and get it back into testing. At this point I think releasing stretch with 2.x would be worse than releasing stretch without freeradius.
Bug#836154: sbuild --no-arch-any --no-arch-all --source fails on all only dsc
package: sbuild version: 0.70.0 severity: normal what happened: $ sbuild --source --no-arch-any --no-arch-all -c unstable -d sid-hadron-snapshot . dh clean dh_testdir dh_auto_clean dh_clean dpkg-source: info: using source format '3.0 (native)' dpkg-source: info: building hadron-ci in hadron-ci_0.1~00+git5e45a12.tar.xz dpkg-source: info: building hadron-ci in hadron-ci_0.1~00+git5e45a12.dsc E: dsc: amd64 not in arch list or does not match any arch wildcards: all -- skipping what I expected: I expected to produce a source package and a _source.changes in a clean chroot.
Bug#836156: improper handling of source+binary changes triggering binary builds
package: mini-buildd version: 1.0.12 severity: normal reprepro 4.17.1-1 The CI on our source control runs sbuild -d sid-hadron-snapshot --arch-all --source . Producing a changes file that includes binaries and sources. If that succeeds in passing some tests, we upload to mini-buildd. I expected it to throw away the binaries and run its own build. As an aside, this is coming from a trusted builder and a trusted chroot; it would be really convenient if there were a way to convince mini-buildd to accept binaries signed by a particular key along with sources. What actually happens is far more annoying. What I know for sure is that if I do a source upload not including the binaries the sources get installed into the repo, but the binaries never do. I tried to debug it. reprepro include is failing, but I don't seem to get the output from reprepro itself in daemon.log. When I unpack the buildresult by hand and run the same reprepro include command, I find that the size, sha-1 and md5 of the .deb are not what is expected. My guess is that the older deb from the initial .changes is getting left in incoming or somewhere where reprepro finds it and because of the rebuild it doesn't match what is expected.
Bug#836193: Improper handling of arch all only package
package: mini-buildd
version: 1.0.12
severity: normal
I uploaded the source of an arch all package (no arch any in the
resulting build) and got:
2016-08-30 22:06:57,398 mini_buildd.packager (0039): ERROR :
Exceptio\
n DEBUG (Package 'hadron-ci_0.2' FAILED: 1 mandatory architecture(s)
missing: a\
md64):
Traceback (most recent call last):
File "/usr/lib/python2.7/dist-packages/mini_buildd/packager.py", line
287, in\
run
package.install()
File "/usr/lib/python2.7/dist-packages/mini_buildd/packager.py", line
140, in\
install
self.repository.mbd_package_install(self.distribution, self.suite,
self.cha\
nges, self.success)
File
"/usr/lib/python2.7/dist-packages/mini_buildd/models/repository.py",
lin\
e 1183, in mbd_package_install
raise Exception("{n} mandatory architecture(s) missing:
{a}".format(n=len(m\
issing_mandatory_archs), a=" ".join(missing_mandatory_archs)))
Exception: 1 mandatory architecture(s) missing: amd64
I'll admit that sbuild isn't great with that situation either; I've
filed some bugs there too.
Bug#836388: When cache is present, job run from incorrect working directory
package: gitlab-ci-multi-runner version: 1.4.2+dfsg-1 severity: important Hi. If a job includes a cache, then it appears that the initial working directory is some directory inside the cache, *not* the top of the project directory. In trying to diagnose build failures I produced the following job: install_test: dependencies: - snapshot_package stage: test variables: DEBIAN_FRONTEND: noninteractive cache: key: "$CI_BUILD_NAME" paths: - apt_cache script: - ' if [ -d apt_cache/cache ]; then cd apt_cache/cache&&tar cf - . | (cd /build/unstable/var/cache/apt&& tar xpf - ); fi' - 'if [ -d apt_cache/lists ]; then cd apt_cache/lists&&tar cf - . |( cd /build/unstable/var/lib/apt/lists && tar xpf - ) ; fi' - mkdir /build/unstable/sbuild_out - git status - pwd - env - ls apt_cache - cp sbuild_out/*.deb /build/unstable/sbuild_out - schroot --directory / -c unstable apt-get update - schroot --directory / -c unstable -- apt-get -y --allow-downgrades -o DPkg::Options::="--force-confold" install ./sbuild_out/*.deb - mkdir -p apt_cache - cp -a /build/unstable/var/cache/apt/. apt_cache/cache - cp -a /build/unstable/var/lib/apt/lists/. apt_cache/lists tags: - debian And I get the following output: [0KRunning with gitlab-ci-multi-runner dev (1.4.2)[0;m [0;m[0KUsing Docker executor with image runner:latest ... [0;m[0KPulling docker image runner:latest ... [0;m[0;33mWARNING: Cannot pull the latest version of image runner:latest : Error: image library/runner not found [0;m[0;33mWARNING: Locally found image will be used instead. [0;mRunning on runner-99528d3b-project-1-concurrent-0 via gitlab-runner... [32;1mFetching changes...[0;m Removing sbuild_out/ HEAD is now at 84b1436 We're getting closer [32;1mChecking out 84b14360 as master...[0;m [32;1mChecking cache for install_test...[0;m [32;1mDownloading artifacts for snapshot_package (150)...[0;m Downloading artifacts from coordinator... ok [0;m id[0;m=150 responseStatus[0;m=200 OK token[0;m= [32;1m$ if [ -d apt_cache/cache ]; then cd apt_cache/cache&&tar cf - . | (cd /build/unstable/var/cache/apt&& tar xpf - ); fi[0;m [32;1m$ if [ -d apt_cache/lists ]; then cd apt_cache/lists&&tar cf - . |( cd /build/unstable/var/lib/apt/lists && tar xpf - ) ; fi[0;m [32;1m$ mkdir /build/unstable/sbuild_out[0;m [32;1m$ git status[0;m HEAD detached at 84b1436 Untracked files: (use "git add ..." to include in what will be committed) ../ ../../sbuild_out/ nothing added to commit but untracked files present (use "git add" to track) [32;1m$ pwd[0;m /builds/hadron/hadron-operations/apt_cache/cache [32;1m$ env[0;m CI_PROJECT_NAME=hadron-operations CI_BUILD_TOKEN= HOSTNAME=runner-99528d3b-project-1-concurrent-0 CI_PROJECT_URL=https://gitlab.hadronindustries.com/hadron/hadron-operations CI_BUILD_BEFORE_SHA=84b143607c165d0dd2e9382d16b20764bc0402e6 CI_SERVER_VERSION=8.11.0 CI_BUILD_ID=151 OLDPWD=/builds/hadron/hadron-operations CI_PROJECT_ID=1 CI_RUNNER_ID=2 CI_PIPELINE_ID=576 CI_BUILD_REF_NAME=master CI_BUILD_REF=84b143607c165d0dd2e9382d16b20764bc0402e6 PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin CI_BUILD_STAGE=test CI_PROJECT_DIR=/builds/hadron/hadron-operations CI_RUNNER_TAGS=debian PWD=/builds/hadron/hadron-operations/apt_cache/cache CI_SERVER_NAME=GitLab CI_PROJECT_PATH=hadron/hadron-operations GITLAB_CI=true CI_SERVER_REVISION=346e677 SHLVL=1 CI_BUILD_NAME=install_test HOME=/root CI_SERVER=yes CI=true CI_PROJECT_NAMESPACE=hadron DEBIAN_FRONTEND=noninteractive CI_BUILD_REPO=https://gitlab-ci-token:@gitlab.hadronindustries.com/hadron/hadron-operations.git CI_RUNNER_DESCRIPTION=Debian Packaging Runner _=/usr/bin/env [32;1m$ ls apt_cache[0;m ls: cannot access 'apt_cache': No such file or directory [31;1mERROR: Build failed: exit code 1 [0;m I can wor around this by changing to CI_PROJECT_DIR, but it seems fairly clear that I'm starting in the wrong place.
Bug#836388: [pkg-go] Bug#836388: When cache is present, job run from incorrect working directory
>>>>> "Dmitry" == Dmitry Smirnov writes: Dmitry> On Friday, 2 September 2016 10:01:14 AM AEST Sam Hartman wrote: >> If a job includes a cache, then it appears that the initial >> working directory is some directory inside the cache, *not* the >> top of the project directory. Dmitry> Please discuss upstream. From the description of the problem Dmitry> I'd say it is an upstream issue. I don't understand the Dmitry> problem well enough to help. Besides it may be worth trying Dmitry> the latest version... I appreciate that you won't be able to help directly, but I'm really frustrated when I am told to "discuss with upstream." We, Debian, have agreed to provide a coherent operating system that works together. Part of what we sign up to do when we agree to maintain packages is to do a fair bit of upstream coordination. I don't know where the upstream bug tracker is. I don't have an account there. I don't wish to get an account there. I don't wish to evaluate whether Debian has applied patches that matter in this space. I know we've significantly changed how the runner image is constructed for example, and I don't think that matters in this instance. But the agreement we make to our users is that we provide a single consistent interface for them to report bugs. If you don't have the skills to work on this issue it's entirely reasonable to forward it upstream. It's also greatly appreciated that you let me know that if I want a faster response I might want to deal with upstream directly. --Sam
Bug#836156: improper handling of source+binary changes triggering binary builds
>>>>> "Stephan" == Stephan Sürken writes: Stephan> Hi Sam, Stephan> On Di, 2016-08-30 at 21:27 -0400, Sam Hartman wrote: >> package: mini-buildd version: 1.0.12 severity: normal >> >> reprepro 4.17.1-1 Stephan> fwiw, I am assuming yor mini-buildd instance runs on an Stephan> (older) sid (or is it jessie+backports?). Older stretch. Stephan> There are currently a bunch of (other) problems on current Stephan> sid I am trying to work out. Noticed that and decided now would not be the time to upgrade:-) >> As an aside, this is coming from a trusted builder and a trusted >> chroot; it would be really convenient if there were a way to >> convince mini-buildd to accept binaries signed by a particular >> key along with sources. Stephan> Ok, sounds reasonable. Maybe you could add a wishlist bug Stephan> for this? Will do. >> What actually happens is far more annoying. Stephan> (...) >> I find that the size, sha-1 and md5 of the .deb are not what is >> expected. Stephan> That sounds strange - I don't recall such an behaviour Stephan> (afaiu it). Will retest binary uploads in my current stint Stephan> ;). Stephan> On your mini-buildd instance, is this limited to one Stephan> special package or a general problem? I don't know. We normally do source only uploads. Actually, it may be arch all handling. The package in question only produced an arch all binary. So, the most direct thing to test would be a binary+source upload of a package producing only an arch all deb.
Bug#837000: kerberos-configs: FTBFS: Undefined subroutine &main::read_config called at ./genblob line 9.
> "Lucas" == Lucas Nussbaum writes: Lucas> Hi, Lucas> During a rebuild of all packages in sid, your package failed Lucas> to build on amd64. Lucas> Relevant part (hopefully): >> fakeroot debian/rules binary ./genblob >tmp &&mv tmp config-blob >> Undefined subroutine &main::read_config called at ./genblob line >> 9. debian/rules:17: recipe for target 'config-blob' failed make: >> *** [config-blob] Error 2 Lucas> The full build log is available from: Lucas> http://people.debian.org/~lucas/logs/2016/09/06/kerberos-configs_2.3_unstable.log Lucas> A list of current common problems and possible solutions is Lucas> available at http://wiki.debian.org/qa.debian.org/FTBFS Lucas> . You're welcome to contribute! Lucas> About the archive rebuild: The rebuild was done on EC2 VM Lucas> instances from Amazon Web Services, using a clean, minimal Lucas> and up-to-date chroot. Every failed build was retried once to Lucas> eliminate random failures. Looks like a . removed from cwd bug in perl. Kerberos-configs is a bit over-due for some love anyway. The fix is easy, but I'll go fold in a bunch of other bugs while I get to it. --Sam
Bug#833798: krb5: FTBFS with -O3: uninitialized variables
Yeah, thanks for reminding me of this. I had intended to apply it from the launchpad bug but just forgot.
Bug#833882: vmdebootstrap: --enable-dhcp doesn't handle resolv.conf
Package: vmdebootstrap Version: 1.5-1 Severity: important When --enable-dhcp is used and systemd-network is used, systemd-resolved is not started. In addition, I think even if you start systemd-resolved, you still need to point resolv.conf at 127.0.0.53. Installing resolvconf and enabling systemd-resolved seems to be sufficient. In the current state, debootstrap copies the resolv.conf from the build system into the machine leaving it there. This is often a very bad choice for the resulting image. -- System Information: Debian Release: stretch/sid APT prefers testing APT policy: (550, 'testing'), (500, 'stable-updates'), (500, 'stable'), (200, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 4.6.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages vmdebootstrap depends on: ii debootstrap 1.0.81 ii extlinux3:6.03+dfsg-14 ii kpartx 0.6.1-3 ii libjs-sphinxdoc 1.4.4-2 ii mbr 1.1.11-5+b1 ii parted 3.2-15 ii python-cliapp 1.20160316-1 ii python-distro-info 0.14 ii python2.7 2.7.12~rc1-2 pn python:any ii qemu-utils 1:2.6+dfsg-3 Versions of packages vmdebootstrap recommends: ii grub2-common 2.02~beta2-36 ii python-guestfs1:1.32.4-2 ii qemu-system 1:2.6+dfsg-3 ii qemu-user-static 1:2.6+dfsg-3 ii squashfs-tools1:4.3-3 Versions of packages vmdebootstrap suggests: pn cmdtest pn pandoc pn u-boot:armhf -- no debconf information
Bug#833882: Duplicate of 831439?
> "Neil" == Neil Williams writes: Neil> Hi Sam, From the description, this sounds like a duplicate of Neil> 831439 vmdebootstrap: stretch image has no DNS setup. The fix Neil> for 831439 enables systemd-resolved and creates the symlink to Neil> /etc/resolv.conf for images based on stretch and later. The Neil> fix is currently pending in the master branch whilst I Neil> investigate some other problems related to kpartx. It is a dup; building something close to stretch; sorry I didn't notice that.
Bug#834035: kdb5_util hangs forever
So, in particular, it looks like kdb5_util is acquiring a lock from 0 to bignum that fails, acquiring a lock from 0 to 0 that succeeds, releasing the lock from 0 to bignum (which succeeds?), and then while still holding the lock from 0 to 0 tries to get another lock from 0 to bignum. At least that's what it looks like if I'm reading that correctly. I don't know what the significance of 6950411022381350912 I wonder if that's uninitialized memory of some kind.
Bug#834035: kdb5_util hangs forever
control: retitle -1 kdb5_util hangs forever on 32-bit systems --Sam
Bug#830344: Moving forward with the Project Roadmap question
I think that calling for that vote would be fine. I view that as an informalish internal vote, not some formal resolution that we're going to announce on d-d-a. Mostly I think we're going to try and figure out the direction at a high level. For options 1, 2, 4, and possibly 3, I think we'll need significantly more discussion before voting on something formalish. If we choose option 1 or 2, we may find that during the process of fleshing something out, we flip-flop back and forth. So, I think that you've done a great job of getting the level of specificity that we need now.
Bug#831187: moonshot-gss-eap: FTBFS with GCC 6: util_shib.cpp:126:5: error: 'template class std::auto_ptr' is deprecated [-Werror=deprecated-declarations]
Hi. Apologies for the delay. I plan to fix this issue this weekend.
Bug#834035: kdb5_util hangs forever
For debian, is there any reason not to build krb5 with _LARGEFILE_SOURCE?
Bug#777182: kerberos-configs: please make the build reproducible
Hi. kerberos-configs also hasn't been uploaded in 555 days:-) It's a fairly static package, and I don't think reproducible builds adds enough value to this package to justify an upload just for this patch. That said, I've reviewed the patch, and it seems entirely reasonable, so I will include it in the next upload. However, looking at the outstanding bugs, #741051 does seem worth dealing with. I'll try to get to something including this patch and that bug in the next couple of months. I'd prefer not an NMU for this issue alone, because the effort of integrating the NMU changes seems lower than the value of getting this package to build reproducibly, but if there is an NMU for another reason I'd recommend including this patch.
Bug#831187: moonshot-gss-eap: FTBFS with GCC 6: util_shib.cpp:126:5: error: 'template class std::auto_ptr' is deprecated [-Werror=deprecated-declarations]
Hi. Apologies for taking a while. I wanted to understand c++ 11 and unique_ptr and shared_ptr better. It turns out c++ 11 is kind of complicated. Replacing auto_ptr with unique_ptr will certainly work in this code at least as well as auto_ptr. Figuring out the upstream patch is a bit more complex because I'm not entirely sure how good Centos6's C++ 11 support is. Will have something shortly; a Debian-only patch is trivial.
Bug#836154: sbuild --no-arch-any --no-arch-all --source fails on all only dsc
I want consistency between the case where there is a binary build and the case where there is a source build. I want --source because I want the source package to be included in the .changes. I want to use one tool, (sbuildh) rather than having my scripts care about how it is being called.
Bug#841372: Kerberos config update for CS.CMU.EDU
Your timing is dreadful.:-) I just uploaded a new krb5-config and am not 100% sure I'll have time to get in another one for stretch before the freeze. I considered dropping the kdc lines and depending on SRV records for cs.cmu.edu, but decided that you were picky enough that you would have sent in an update request if you wanted one:-( I'll see what I can do. I need to wait for 2.5 to get into testing before uploading a 2.6 because 2.5 is really needed.
Bug#833057: does downgrading e2fsprogs to the jessie version help?
Does the e2fsprogs in jessie produce an image that works with syslinux and vmdebootstrap?
Bug#805154: Please reconsider tagging this bug wontfix
I do understand that the proposed fix is inadequate. You'd need to not include nobarrier on the esp partition. However, the performance of vmdebootstrap is really fairly bad compared to other image creation solutions I've used in the past, and it does significantly impact the test/development cycle. If you don't want to develop a patch fine, but perhaps help or no tags would be more appropriate than wontfix.
Bug#841372: Kerberos config update for CS.CMU.EDU
control: severity -1 important justification: As maintainer, I'd like to consider this issue important. If not promptly resolved, it will create an operational inconvenience on an ongoing basis for years. --Sam
Bug#841372: Kerberos config update for CS.CMU.EDU
Jeff, I've just uploaded kerberos configs 2.6. If you delete /etc/krb5.conf and then install krb5-config 2.6 and confirm that the entry there works for you, I'll fill out paperwork to request an unblock for stretch. (I don't think this will make it for the auto migration)
Bug#838393: PCA on a repository insufficient to update uploaders
package: mini-buildd version: 1.0.12 Hi. I'd expect that if I change the extra keyrings configuration in the repository, and then prepare/check/activate the repository, then any new uploaders would be able to upload. I've found that I need to restart the demon (I used systemctl, although perhaps starting/stopping the daemon in the web interface would have been sufficient). It looks like what's happening is that the cache mapping repository identities to uploader keyrings is stored on the demon object in the _uploaders field and this isn't being refreshed when a repository is reconfiged. You could argue that cache is a demon thing, and so it is proper behavior, but it's very confusing. I think it would be worth having repository reactivation trigger refreshing that cache. --Sam
Bug#838393: PCA on a repository insufficient to update uploaders
So, I can see a couple of easy fixes: 1) have _uploaders be a class variable rather than an instance variable or 2) store a list ofweakrefs to extant demon objects then provide a class method to invalidate all the uploaders caches.
Bug#835086: RFP: nextcloud -- self-hosted cloud services
> "Xavier" == Xavier Bestel writes: Xavier> Le mardi 20 septembre 2016 à 19:38 +0200, Moritz Mühlenhoff Xavier> a écrit : >> On Mon, Aug 22, 2016 at 12:02:59PM +0200, Xavier Bestel wrote: >> > >> > Package: wnpp > Severity: wishlist >> > >> > * Package name: nextcloud Xavier> [...] >> > Given that Nextcloud is an Owncloud fork, with the same people >> > behind it, and that Owncloud upstream has always had a >> difficult > relationship with distro maintainers, there may be >> problems for > packaging that correctly. > But Nextcloud is >> still a highly relevant package for Debian. >> >> Nack. It's not an important package if we can't support it >> properly. Let's not repeat the owncloud disaster. Xavier> OK, I understand the "official" debian point of view. I don't think this is an official Debian POV, simply the opinion of some Debian contributors... Well, I think it is the official Debian POV that in order to include a package, we need to be able to support it. Whether we will or will not be able to support nextcloud is up to interpretation. >From a user standpoint, having something that has the functionality of opencloud/nextcloud is quite important in the enterprise space. However, we do need to be able to get things to work. --Sam
Bug#830344: Project Roadmap question - Call for votes
>1) The TC volunteers to be the Roadmap team >2) The TC volunteers to be part of the regular workflow of the >Roadmap team, as an advisory body. >3) The TC shouldn't be part of the regular workflow of the Roadmap team. >We will always be available for escalations, as usual. >4) Further Discussion. >Additionally, I'd like to ask each TC member to state if they would like >to be part of the initial group for the Roadmap team if option 1 doesn't win. I vote 2>1=4>3 I'm happy to be part of a discussion of what the roadmap process is , but I don't understand it well enough to know whether I'd be a good member of the initial team. signature.asc Description: PGP signature
Bug#830344: Project Roadmap question - Call for votes
>>>>> "Sam" == Sam Hartman writes: >> 1) The TC volunteers to be the Roadmap team 2) The TC volunteers >> to be part of the regular workflow of the Roadmap team, as an >> advisory body. 3) The TC shouldn't be part of the regular >> workflow of the Roadmap team. We will always be available for >> escalations, as usual. 4) Further Discussion. >> Additionally, I'd like to ask each TC member to state if they >> would like to be part of the initial group for the Roadmap team >> if option 1 doesn't win. Sam> I vote 2>1=4>3 Sam> I'm happy to be part of a discussion of what the roadmap Sam> process is , but I don't understand it well enough to know Sam> whether I'd be a good member of the initial team. In the interest of closing this vote, and in acknowledgement that we seem to continue to have an energy problem, I change my vote to 3>2>1=4 if and only if that change makes the vote no longer in doubt. Now you can all fight about whether I can do that:-) signature.asc Description: PGP signature
Bug#835507: Please clarify that sysvinit support decision is not going to expire
Ian, quick question for you because you might know the answer off the top of your head. Does running stretch with sysvinit as your init system work reasonably well, or at least work well enough that there are a small number of bugs we will likely be able to fix in the stretch time frame? What I say below is predicated on the assumption that init scripts are basically functional for stretch. If that's not true I'd need to rethink my position. I think we want to reaffirm that policy section 9.3.2 and section 9.3.3 represent current policy for init scripts, quoting particularly the following text from section 9.3.2: Packages that include daemons for system services should place scripts in `/etc/init.d' to start or stop services at boot time or during a change of runlevel. I think it is also reasonable to reaffirm that this is Debian policy until changed through the policy process or by the TC. I don't want to make a blanket statement that it's a bug not to include an init script. The systemd package includes a number of daemons and services and installs no init scripts, and no really, that actually is the right answer for that package. Policy should basically means bug of normal severity. (I've always wished that the policy people would be a bit more nuanced especially when taking a term from RFC 2119, which more-or-less already includes the nuanced language they need, but people seem to do a fairly good job of accepting the nuances even though that's not quite what policy says.) I do *not* want to get into describing all the cases where it is a bug to not include an init script, nor do I want to get into all the cases where it isn't. The TC tried to do that during the systemd discussion with text for the L and T varients of options. I think they did about as well as they could, but I think a policy should better captures the reality of the situation than the TC's previous best efforts. I think including 6.1.5 language saying that we encourage maintainers to merge patches adding support for init systems including init scripts would be valuable. I think we have such language floating around from previous resolutions to re-use.
Bug#835507: Please clarify that sysvinit support decision is not going to expire
>>>>> "Ian" == Ian Jackson writes:
Ian> Sam Hartman writes ("Re: Bug#835507: Please clarify that
Ian> sysvinit support decision is not going to expire"):
>> Ian, quick question for you because you might know the answer off
>> the top of your head. Does running stretch with sysvinit as your
>> init system work reasonably well, or at least work well enough
>> that there are a small number of bugs we will likely be able to
>> fix in the stretch time frame? What I say below is predicated on
>> the assumption that init scripts are basically functional for
>> stretch. If that's not true I'd need to rethink my position.
Ian> I am running stretch with sysvinit on my laptop. It seems to
Ian> work for me. I haven't conducted any kind of systematic
Ian> survey.
That's the rough estimate I thought you could provide easily and was
looking for.
That's good enough that I definitely support reaffirming policy 9.3.2
and 9.3.3.
Bug#835520: Policy 9.3.1 is inaccurate to the point of being harmful
package: debian-policy severity: normal Hi. As part of reviewing an issue for the technical committee, I just read policy section 9.3 in its entirety. Section 9.3.1 really seems to be showing its age. That section covers runlevels and the sequencing numbers after S and K in rc.d links without reference to dependency-based boot ordering, init systems other than sysinit, etc. In an ideal world I'd encourage that section to be updated to talk about how boot ordering works on modern Debian. Absent that, I'd recommend significantly trimming the section to just cover the fact that there are run levels and that there are these numbers after S and K and not go into what the numbers after S and K mean.
Bug#835507: Please clarify that sysvinit support decision is not going to expire
>>>>> "Ansgar" == Ansgar Burchardt writes: Ansgar> On Fri, 26 Aug 2016 08:50:13 -0400 Sam Hartman wrote: >> I think we want to reaffirm that policy section 9.3.2 and section Ansgar> 9.3.3 >> represent current policy for init scripts, quoting particularly >> the following text from section 9.3.2: Packages that >> include daemons for system services should place Ansgar> scripts >> in `/etc/init.d' to start or stop services at boot time or Ansgar> during a >> change of runlevel. Ansgar> Does this really represent current policy? Ansgar> As far as I can tell Policy still assumes that sysvinit is Ansgar> the default init system and everything else is an "alternate Ansgar> init system" (9.11). There are many problems with regard to policy and init systems. I believe that 9.3.2 on init scripts and 9.3.3 on update-rc.d are still our current policy and still solid. The rest of policy in this area really needs to be updated, but if you see specific problems with those sections, please explain them. I did a complete review this morning and they seemed fine to me, especially if you take more of an RFC 2119 interpretation of SHOULD than we classically have admitted we take in policy.
Bug#835507: Please clarify that sysvinit support decision is not going to expire
> "Bart" == Bart Schouten writes: >> I agree on this too. To the extent it should be considered >> time-limited, it should be «until N releases after sysvinit is >> removed» or somesuch, if that happens. Bart> In legal terms, in law, it would be considered that the burden Bart> of proof lies with those who want to remove it. Bart> Asking the supporters of those scripts to prove that they Bart> still need them would be considered an unreasonable burden. I'm nervous of going too far down the path of legalisms. Asking those who need the scripts to prove (or even say) they still need them is not what we want. However if someone is having difficulty maintaining the scripts or they are broken, it is reasonable for them to ask for help, and if no one steps forward, eventually the scripts will become buggy enough that the normal severity bug of a package without an init script is better than the state of a package with a broken init script. Similarly, if the community of people who care about sysvinit is unwilling to spend the time keeping it working, eventually sysvinit as a whole will be unmaintained and buggy.
Bug#821361: Voting for CTTE Chair
A: Don Armstrong B: Andreas Barth C: Phil Hands D: Sam Hartman E: Tollef Fog Heen F: Keith Packard G: Didier Raboud ===END=== I vote g>B=E>F=D=C>A for TC chair. pgpjaqMmOsHJ3.pgp Description: PGP signature
Bug#839172: TC decision regarding #741573 menu policy not reflected yet
package: tech-ctte In #741573, the TC produced a two-part decision. We approved specific wording regarding .desktop policy. That was folded into a policy NMU. We also approved the decision that packages should not include both a menu file and a desktop file. The action to draft language for that has stalled in the policy process. At the August, 2015 meeting, we agreed to champion our decision in the policy process and propose specific language. Also at that meeting we agreed to prioritize that work below helping out with an init system policy.
Bug#839570: Browserified javascript and DFSG 2 (reopening)
I'd be willing to vote on the ballot you propose. I disagree with your rationale for why this bug is not for the TC to decide. But I agree that this bug is not for the TC to decide at this time. So, if that's all we're voting on, and I don't need to agree with your rationale to vote C, I'm fine with your ballot.
Bug#839570: Browserified javascript and DFSG 2 (reopening)
> "Didier" == Didier 'OdyX' Raboud writes: Again, I'm fine with your current ballot. As stated, I don't think the TC should (and am skeptical of can) decide on the DFSG-freeness of a package directly. We could mediate, but it's clear we don't want to here. I do think there are things we could do in this space. We could set policy consistent with the DFSG on what the definition of source code in Debian is. So, I think there are things that we might be permitted to do related to this issue. We could always issue a statement. It's just that I think when all the circumstances are considered, we shouldn't do any of those things for this bug, given our IRC discussion.
Bug#839570: Browserified javascript and DFSG 2 (reopening)
Dear Pirate: I hear that you're fairly frustrated by the response you're getting from the TC. Speaking as someone who has read extensively the earlier bug log, I think that your cause would be advanced by getting an additional primary advocate who has a better understanding of what the TC can do, what the TC is likely to do, and who can more articulately ask for things to advance your position. If Joseph were more involved in Debian, I'd suggest him as a possibility. You're asking questions that don't make sense from a p.process standpoint, doing things that have a very low probability of making anyone happy, and not responding to advice people have given you on how to move forward.
Bug#839570: Browserified javascript and DFSG 2 (reopening)
Dear joseph: This message will be hurried: I'm on a train and approaching my stop. Thanks for your detailed message. I don't agree with all of it, but I find it a lot easier to interact with than some of the requests we've gotten related to this issue. Here are some factors to consider: 1) It's not clear to several TC members that the FTP team has decided on this question. It seems fairly clear how they would decide if they did decide, but from a process standpoint, it's important to have a formal dialogue with them before they are overruled. 2) It's not clear constitutionally that the TC can overrule the ftp team's decision regarding whether something is DFSG-free. Even if we could, it's not clear that is a technical decision in our scope. So, asking the TC to overrule such a decision is asking for the hardest political choice possible in such a situation--a really hard sell within the project and the TC. 3) We'd need a rationale for overruling someone. That might not be a strict requirement, but if we're going to say that "browserified javascript" is DFSG-free, what exactly are we saying? There was a discussion of what is source code, with a number of different considerations brought up. Something that was responsive to that part of the discussion would be a lot more likely to move things forward than simply an assertion. I don't even have a clear enough understanding of what browserified means to have any understanding of what a ruling based on those terms would mean. Put another way, the TC is more comfortable acting when it's building a coherent policy that fits together. To gain traction, a ruling almost certainly needs to fit into some intellectual framework about what source means. It's quite unlikely that we'd decide something was source simply because it would be inconvenient for us and our users if it were not source. User convenience is something we're likely to consider, but "source is what we need source to be so things work well for users," is going to be a really improbable sell.
Bug#822803: Call for votes for new TC member
> "Didier" == Didier 'OdyX' Raboud writes: Didier> Dear TC members, I hereby call for votes on the following Didier> ballot to fill the vacancy in the TC. The voting period Didier> starts now and lasts for up to one week, or until the Didier> outcome is no longer in doubt. Didier> ===BEGIN Didier> The Technical Committee recommends that Margarita Manterola Didier> be appointed by the Debian Project Leader to the Didier> Technical Committee. Didier> MM: Recommend to appoint Margarita Manterola FD: Didier> Further Discussion Didier> ===END I vote mm > fd pgpXCV5vp72rh.pgp Description: PGP signature
Bug#829671: krb5-config: debconf seeding is not working when installing/reconfiguring the package
In general, the krb5 configuration should respect values already in /etc/krb5.conf if there is an existing krb5.conf on the system, and the values from that file will override preseeding. That's according to debian policy and I can look up the reference if you'd like. However, if there is no krb5.conf, values from the debconf database should be used and preseeding should work fine. If you purge the package, then the file should be removed, and so should your preseeding. purge package debconf-set-selections install package should behave the same as a fresh install. If the above is not the behavior you're seeing, please clearly explain which case fails to do as I've described and I'll be happy to look into it. If you think the above behavior is not what is required by debian policy, also let me know and we can discuss. --Sam
Bug#829704: Voting for TC Chair
The ballot is the following: ===BEGIN=== The chair of the Debian Technical Committee will be: A: Andreas Barth B: Don Armstrong C: Keith Packard D: Didier Raboud E: Tollef Fog Heen F: Sam Hartman G: Phil Hands H: Margarita Manterola ===END=== I vote d > c=e=f=g >h > a=b signature.asc Description: PGP signature
Bug#829749: krb5-kdc-ldap: kerberos.schema.gz is a config file
I'm not entirely sure either. One thing to consider is that Debian's openldap doesn't typically use schema files; it instead uses the ldap configuration schema, so you'd need to produce an ldif of the schema and submit that to Kerberos. That is in fact a major pain and I'm open to thoughts about how to improve this. Including it as a documentation/example makes it clear that the user needs to deal with enabling the schema in their ldap server. However if we can better automate that would be good. --Sam
Bug#830213: tracker.debian.org: Accessibility regressions over old pts
Package: tracker.debian.org Severity: important Hi. The new tracker is significantly less accessible using the Orca screen reader on firefox than the old PTS. The big problem is that I cannot find a way to easily expand the collapsed tabs, so I cannot get to most of the information. to reproduce, install gnome-orca, and connect to tracker in firefox. This is probably a reasonably simple css fix. -- System Information: Debian Release: stretch/sid APT prefers testing APT policy: (550, 'testing'), (500, 'stable-updates'), (500, 'stable'), (200, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 4.6.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system)
Bug#830213: tracker.debian.org: Accessibility regressions over old pts
>>>>> "Raphael" == Raphael Hertzog writes: Raphael> Hi Sam, Raphael> On Thu, 07 Jul 2016, Sam Hartman wrote: >> The new tracker is significantly less accessible using the Orca >> screen reader on firefox than the old PTS. The big problem is >> that I cannot find a way to easily expand the collapsed tabs, so >> I cannot get to most of the information. Raphael> I guess that you are referring to "action items" which hide Raphael> the details. Is that correct? Raphael> The chevron that controls the expansion of the action item Raphael> is accompanied by a "[Toggle details]" string which is Raphael> supposed to be shown to screen readers only because it has Raphael> a CSS class of "sr-only" which is provided by the default Raphael> bootstrap CSS. That part works. What fails is that I cannot interact with that string because Orca thinks it is neither a link nor clickable.
Bug#830213: tracker.debian.org: Accessibility regressions over old pts
Now I can interact with the toggle details string, but nothing happens when I do. Since you've made it a link, I'm going to interact with it that way. Are you expecting it to be clicked on rather than selected as a link? Other accessibility problems: * The page is hard to navigate. There are no headings, and none of the screen reader controls for navigating the page work, so you have to scroll through the whole thing. * In the table listing versions and letting you look at the changelogs/control files/etc, we have the same hard/impossible to interact with items problem as with the action needed display. --Sam
Bug#830213: tracker.debian.org: Accessibility regressions over old pts
>>>>> "Raphael" == Raphael Hertzog writes: Raphael> Hi Sam, Raphael> On Fri, 08 Jul 2016, Sam Hartman wrote: >> Now I can interact with the toggle details string, but nothing >> happens when I do. Since you've made it a link, I'm going to >> interact with it that way. Are you expecting it to be clicked on >> rather than selected as a link? Raphael> Yes, the toggling is managed by the javascript onClick Raphael> event on a parent tag, so you should click on the Raphael> link. I can't. If it's a link, the screen reader lets me execute the action associated with the link, not the onclick action. If you want me to click on it you'll need to manipulate it so the screen reader thinks it is clickable. There are some cases wher I can click on a link using some screen reader mouse interaction, but it's unreliable, and it's better to either click on something the screen reader thinks is clickable or run the link action associated with something the screen reader thinks is a link. >> Other accessibility problems: >> >> * The page is hard to navigate. There are no headings, and none >> of the screen reader controls for navigating the page work, so >> you have to scroll through the whole thing. Raphael> Are there "aria" attributes that we can set on title of Raphael> panels to get them recognized as headings or interesting Raphael> navigation points? I do not know. I'm not a web front end person; I don't know CSS. I'm an end user in this space. Raphael> I could change them to but I would then have to Raphael> disable all default styles that apply to this tag. >> * In the table listing versions and letting you look at the >> changelogs/control files/etc, we have the same hard/impossible to >> interact with items problem as with the action needed display. Raphael> Here I really don't understand... we have a link and within Raphael> that link we have the icon and the Raphael> tag with the text that you are supposed to see. And given Raphael> it's placed within the link, you should be able to interact Raphael> with it. That's not what I'm seeing.
Bug#830667: speechd-el: Fails to honor XDG_RUNTIME_DIR
Package: speechd-el Version: 2.7-1 Severity: grave Justification: renders package unusable In modern gnome at least, speech-dispatcher's socket lives in XDG_RUNTIME_DIR, which is rooted at /run/user/uid. This package seems hard-coded for unix sockets in the user home directory, so it doesn't work on stretch GNOME. I file as grave because I believe enough users who want accessibility will be using gnome to make the package generally unusable. If your analysis of the user base is different, then perhaps it is only important. Either way it would be nice to fix. -- System Information: Debian Release: stretch/sid APT prefers testing APT policy: (550, 'testing'), (500, 'stable-updates'), (500, 'stable'), (200, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 4.6.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages speechd-el depends on: ii base-files 9.6 ii emacs23 23.4+1-4.1+b1 ii emacs24 24.5+1-6+b2 ii emacsen-common 2.0.8 ii make4.1-9 Versions of packages speechd-el recommends: ii sharutils 1:4.15.2-1 Versions of packages speechd-el suggests: pn brltty ii speech-dispatcher 0.8.4-2.1 pn speechd-el-doc-cs -- no debconf information
Bug#830213: tracker.debian.org: Accessibility regressions over old pts
> "Raphael" == Raphael Hertzog writes: Sort of. First, that didn't make it clickable. In general, I'd expect focusing on a button and pushing space to activate the button. Enter sometimes activates a default action for a form, and definitely is the wrong keyboard approach to pushing a button outside a web browser. However, I think most people will try enter when space fails. However, there is a mechanism for activating a button directly that works, and as you say, hitting enter after tab focusing works. Luke Faraone (copied) said he'd be willing to help out with this. He has much more accessibility experience at the css and html layer than me.
Bug#830344: How should the TC help with a project roadmap?
Here are my thoughts on the road map and TC involvement. There is value in two levels of thing: * Goals that we've committed totrying as a community. For these, RC bugs or NMUing a package are valuable. At this level it's desirable to have review of the plan to achieve a goal. It's frustring to make a bunch of stuff RC buggy only to later realize that even if you had fixed those bugs you never would have gotten to the goal. I think that review needs to be positive--some people need to say yes, not simply no one raises objections. Also, it needs to be reviewed to make sure all the stakeholders are involved. * Second level: wishlist. Things people think would be valuable. Easy to add to. May not represent project-level commitment to try for the goal. You may not want people NMUing at this level. As an example, removing build information from a binary package does sometimes make debugging harder. If we're not actually going to achieve reproducible builds, it's not clear that making those changes is valuable. (In the specific case of reproducible builds, we've met the bar already, but the point stands as a generalization) TC skills that may help here: 1) Across the entire TC we have a moderately good coverage of things in the project. There are probably gaps. Across the TC we have fairly good coverage of who to go to for more depth about a given issue. 2) We're builting a TC that's good at working with people and helping facilitate communication. 3) We can do technical review for completeness of a proposal. One area where I'd like to the see the TC help is to try and avoid late stakeholders appearing. That is, you put together a plan, start working on it, and then discover late in the process that you missed some key player, and they disagree with your goal. So you invest a bunch of time and run up against a stone wall. I think if we worked on it we could be fairly good at making sure people have talked to a lot of the stakeholders they need. I really hope the process supports that sort of review because I believe it could significantly help with burnout avoidance.
Bug#830796: pidgin-otr: You don't have OTR link could be more useful to debian users
Package: pidgin-otr Version: 4.0.2-1 Severity: wishlist Almost all the users at our company are Debian users. If you don't have pidgin-otr installed, your are linked to https://otr.cypherpunks.ca As a co-worker just pointed out to me it's really hard to get from there to finding that you want to run apt-get install pidgin-otr. I understand this issue is complicated, because there's no guarantee that just because I'm using Debian the person I'm talking to is. First, I think that in a number of cases you can tell whether the remote party is Linux--I think XMPP especially does the capability negotiation to figure that out, although I can totally understand not wanting to deal with that. Secondly, it would be nice if some Debian specific text could be added in addition to the generic text, because after all using Debian to talk to Debian is a reasonably common thing. -- System Information: Debian Release: stretch/sid APT prefers testing APT policy: (550, 'testing'), (500, 'stable-updates'), (500, 'stable'), (200, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 4.6.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages pidgin-otr depends on: ii libc62.22-11 ii libgcrypt20 1.7.1-2 ii libotr5 4.1.1-1 pidgin-otr recommends no packages. pidgin-otr suggests no packages. -- no debconf information
Bug#830796: pidgin-otr: You don't have OTR link could be more useful to debian users
Your proposed format string replacement looks good. I don't have the available time to start a conversation with upstream about the OS detection etc. I was just reporting a wishlist bug because I ran across this helping a user. I think the format string fix is likely to be a good compromise between time and effort.
Bug#830978: Browserified javascript and DFSG 2
So, my first question is whether this is a matter that it's reasonable for the TC to rule on. I definitely think we're not an appropriate body to rule on a question like whether a particular license is DFSG free. However, here we're asked to give advice on whether something is source code. Is the question of what is the source code for a given package technical, and thus within our remit? I'd be very interested in opinions on this.
Bug#830978: Browserified javascript and DFSG 2
> "Paul" == Paul R Tagliamonte writes: Paul> Traditionally, ftpteam has had to take this role, since it is Paul> the body that decides if an upload is fit for main. Paul> I am one of those folks that treat minified JS as binary, Paul> since things like removing comments and renaming variables to Paul> `a`, `b` `c` is done. Dead code can also be trimmed (closure Paul> compiler). In my mind it's not hugely different than compiling Paul> nasm to an ELF. It may relate closely, but it's not how you'd Paul> modify it. Paul, ftpmaster, would you be willing to give us a bit of time to figure out if there's anything here for the TC to get involved in before we jump into reopening the discussion of what is source code? I'd hate to be a week into a long involved discussion and then realize that the bug is in the wrong place. --Sam
Bug#830978: Browserified javascript and DFSG 2
Hi. Speaking as an individual TC member, here's my personal reading of the TC discussion. It's not clear that the TC is the right body for this discussion. We certainly could offer advice, but it's not clear that the ftpmasters or release team--the parties most likely to need such advice-- would benefit from our advice. It doesn't sound like you are looking for help trying to understand another position. As I read your message, you understand what is being said,you just don't agree with it. There seems to be general agreement within the TC that it makes sense to close the bug, effectively saying that it doesn't sound like there is anything for the TC to do here. Based on my reading of the discussion, I plan to close the bug some time next week unless at that time there have been further developments. I'd especially hold off if a TC member wants to discuss giving particular advice. It sounds like some TC members will be skeptical of doing that, but I'd love to hear the argument. If the bug gets closed, it will be a soft close--we wouldn't mind the issue being reopened if there is new information, or a new formulation of a question, etc. --Sam
Bug#830978: Browserified javascript and DFSG 2
> "Ian" == Ian Jackson writes: Ian> I would like to comment briefly on the general idea about the Ian> TC offering advice and making statements of opinion. Ian> If someone in authority in the project, such as a maintainer of Ian> the ftpmasters or the release team, is doing something which Ian> the TC thinks is wrong, then (if the question is important) I Ian> think it would be entirely appropriate for the TC to issue a Ian> statement of opinion, disagreeing with the other authority. Ian> Conversely, if a contributor has been criticised, they may Ian> welcome a message of support from the TC. That may help lay to Ian> rest an unfounded criticism and save the contributor the energy Ian> required to wonder whether they're really right, rebut any Ian> public criticisms, and so on. Ian> And finally if a question needs authoritative input but the Ian> relevant authority in Debian has not made a clear decision, TC Ian> involvement might help get the matter properly resolved. Agreed on both the first two points. Also, from the discussion on IRC, it seems fairly clear that most TC members agree that we can give advice if we wish. I agree in general on the third point about authority and clear decisions, with a lot of emphasis on the "might." Sometimes that's good, sometimes it is not. Ian> In this case I think that it would be worth TC members Ian> considering, for themselves, briefly, and without too much Ian> back-and-forth enquiry, what their initial assessments of the Ian> merits of the situation are. I'm fairly sure that's happened for a majority of the TC members. Ian> If TC members feel that the submitter of #817092 (Luke, who is Ian> complaining that the aggregated file is not source, along with Ian> Ben, Jonas etc.) are right, they could ask the release team and Ian> the ftpmasters (informally, perhaps) whether the release team Ian> would welcome a supportive TC intervention. The release team has indicated that this call is the FTP team's. The members of the TC and members of the FTP team have talked informally. Ian> That would allow the TC to help settle this long-running Ian> question (which keeps coming up on -devel and is frankly quite Ian> annoying). So, here's why I personally don't think that would be helpful. I want to emphasize this is pure Sam, not even Sam making a best guess at how things might fall out if other people got involved, not me giving my read on anything else. As best I can tell, the ftp team has a clear position; it is reflected in their new rejection FAQ, and in their decisions. (As an aside, there was a keynote at Debconf talking about how it would (in the speaker's opinion) be better to get more transparency in that. Based on what I heard at the keynote I think getting the TC involved in that would slow it down/make it more political) I haven't seen a lot of doubt expressed from the ftp team about what its policies are. You see careful language from people not wanting to step on each others' toes, but they are all saying the same thing. Having an outsider to the process like the TC say something isn't going to help in a case where there is already fairly good internal consensus and not a lot of doubt. I think the reason this comes up on -devel is that there may not be a consensus project-wide, and if there is a rough consensus project-wide on this issue, it's really on the rough side. In general, I think that those who spend a lot of time in Debian are more radically pro-free-software than the developers as a whole. That is, folks on the TC, the DPL, the ftp team, etc are probably not representative of the developers overall. I think we've seen this when we've taken things like getting rid of non-free or binary firmware to a GR. The project is clearly pro-free-software, but also fairly clearly pro-getting-stuff-done-for-real-users even when that gets messy with regard to free software. Part of having good governance is to have those discussions on devel. You have an honest disagreement between parts of your community--between the people deciding and the people affected by the decisions. That's not inherently a sign that the people deciding are wrong: Debian culturally chooses to give significant power to those doing the work. The TC isn't going to be able to add anything here. We have similar biases to the ftp team. We deal with licenses less often, so they are probably even more aware of the issues than we are. Having two teams say the same thing isn't going to shut up anyone on devel frustrated that we're insisting they do significantly more work. We also need to continue to pay attention to those discussions and bugs filed like this. If we find that the overall project unhappiness with the balance we strike is growing, we need to do something. That said, my personal opinion about this issue is that it is a datapoint, not a tren
Bug#830978: Browserified javascript and DFSG 2
> "Neil" == Neil Williams writes: >> > * The point of having the source code (with an appropriate >> licence > etc.) is so that all our contributors, downstreams, and >> users are > able to modify the code and to share their >> modifications with each > other, with Debian, and with upstream. >> >> I agree this is an important consideration, but not serious >> enough to reject a package. Neil> So you consider that upstream are not fully-qualified users Neil> somehow and therefore do not get the benefits of the DFSG? If Neil> the freedoms of users who choose to interact with upstream are Neil> reduced by choices made within the package then the package is Neil> breaking the DFSG by penalising a field of endeavour. Neil, I have a fairly strong negative emotional reaction when I read the paragraph you wrote. I'd like to share that because I think if I share where I'm coming from it will be easier for me to hear you, and easier to participate calmly. When I read the above, I'm worried because I think that freedoms I care about would be limited, and I don't like to see the DFSG reshaped to limit freedoms. I'm afraid when I think I hear us seeding the contents of Debian to upstream. We are Debian; we choose what Debian is. I want to stress that I think you and I are in agreement on handlebars. However, I do think the freedom to fork from upstream, to move away from upstream practices we disagree with is important. I also think that the freedom to "free," over time software even in cases where upstream has a non-free source control system, or where we're having to build up a new form of source code because of restrictions on what's currently the source code are important. I do not agree that being an upstream is a field of endeavour. I do not agree that we must always use the same source code form that upstream does. Sometimes upstream is wrong. Sometimes there are multiple upstreams. Sometimes we want to fork. We do however need to ship the source code we use whatever that is. It needs to really be source code. It needs to be a reasonable form in which we would choose to make modifications. If there are other plausible source forms that are being used (even if some of them are non-free), and those source forms would make the modifications easier, that's a strong argument that the software is probably not free as we propose to ship it. I do not wish us to make the upstream form of source so special that we in our best judgment cannot override it. I do hear your worry that you want to be able to exchange modifications with upstream. Without modifications, without free flow of those modifications, software is not free. I ask that we have the flexibility to reject people who aren't actually shipping source they would use to modify software while accepting people who legitimately disagree about what the source form is.
Bug#1065011: libpam0t64 competes for libpam.so.0 symlink against libpam0g (breaks debootstrap)
I wanted to briefly summarize an irc conversation we had on #debian-devel for anyone reading this bug. In general, we want to get rid of libpam0g as soon as possible, because you cannot have both libpam0g and libpam0t64 installed at the same time. Steve is working on a series of NMUs to make that possible on arches where the ABI has actually changed. On arches where the ABI is the same, libpam0t64 provides libpam0g, so we can get rid of libpam0g today. --Sam
Bug#1065017: unuser: error while loading shared libraries: libpam.so.0
> "Helmut" == Helmut Grohne writes: Helmut> I believe pam will have to be reverted and implemented as Helmut> dual ABI instead. I'm not very comfortable with this approach. The tentative patch did not fill me with confidence; my gut is that it was not as robust as an approach that libraries like libc6 took, and unfortunately I do not have enough experience with the internals of libc6 and various multi-ABI approaches across the years to have confidence either way. I could use some help from someone who has approached this sort of issue and deployed changes like this in production. Steve and I agreed to revert the rename on IRC, effectively accepting the ABI break because it doesn't matter for the archive. We may look at better solutions when we have a bit of time. --Sam signature.asc Description: PGP signature
Bug#1065064: libpam-doc: doc-base reports missing files
> "Colin" == Colin Watson writes: Colin> in those doc-base files but are in fact missing. I don't Colin> know whether this is intentional (in which case the doc-base Colin> registrations should be removed to match), or an accidental Colin> build issue that should be fixed. I think this is probably a build issue with the 1.5.2 -> 1.5.3 upgrade. There were a number of doc changes. I'm going to prioritize getting the archive working again over this:-) but will get to it in a few days. signature.asc Description: PGP signature
Bug#1065088: pam 1.5.3-5 not suitable because pam_userdb is missing
package: pam version: 1.5.3-5 severity: serious This version of pam drops pam_userdb which can break systems that use pam_userdb in their configuration. Long term we do want to split it out and possibly drop. However, this change is purely for the time_t transition and will be reverted. This version of pam is not suitable for testing.
Bug#1065017: unuser: error while loading shared libraries: libpam.so.0
> "Christoph" == Christoph Anton Mitterer writes: Christoph> Do you happen to know whether there's anything needed in Christoph> terms of clean up for people who had already upgraded Christoph> now? Like manually doing whatever was done via the Christoph> runuser? I think that so long as libpam0g 1.5.3-5 installs cleanly, it will be fine. I think that the runuser is from debian-security-support and is run on every upgrade, so you should be good there. I tried to make the revert work either if you didn't have libpam0t64 at all or if you did, but we're more focused on people who never upgraded. If you do run into breakage, we'll work with you to find a solution. --Sam
