Bug#754462: Bug#862051: nodejs (6.11.2~dfsg-1) experimental; urgency=medium

> "Dominique" == Dominique Dumont writes: Dominique> On Thursday, 31 August 2017 13:58:23 CEST Thorsten Glaser wrote: >> > How about printing a "nice" warning explaining it would be a >> good idea to > move to /usr/bin/node ? >> >> That will break

Bug#862051: [Pkg-javascript-devel] Bug#754462: Bug#862051: nodejs (6.11.2~dfsg-1) experimental; urgency=medium

> "Julien" == Julien Puydt writes: Julien> Hi, Le 31/08/2017 à 13:52, Jérémy Lal a écrit : >> How about printing a "nice" warning explaining it would be a good >> idea to move to /usr/bin/node ? Then in next next release drop >> the nodejs symlink.

Bug#754462: Bug#862051: nodejs (6.11.2~dfsg-1) experimental; urgency=medium

> "Didier" == Didier 'OdyX' Raboud writes: Didier> For good reasons, Debian forcibly introduced a special-case Didier> when Node.js first appeared in a stable release through only Didier> shipping it under /usr/bin/nodejs. That forced hundreds of Didier>

Bug#873563: CVE-2017-11462 -- automatic sec context deletion could lead to double-free

OK, let's give the security team some context. RFC 2744 specifies some kind of unfortunate behavior for error handling. gss_init_sec_context and gss_accept_sec_context have an in/out context parameter (pointer to pointer). You initialize the pointed to value to null the first time through. It

Bug#754462: Bug#862051: nodejs (6.11.2~dfsg-1) experimental; urgency=medium

> "Thorsten" == Thorsten Glaser writes: Thorsten> Hi, >> * Restore /usr/bin/node following CTTE #862051 Let's try to drop >> /usr/bin/nodejs before buster. Replaces and Conflicts >> nodejs-legacy. Closes: #754462. Thorsten> please do NOT completely

Bug#873563: CVE-2017-11462 -- automatic sec context deletion could lead to double-free

Ah, looked at the commit. Yeah. This makes sense. This is somewhat of a behavior change. Do we want to just bring this into unstable, or do we want to backport it to stable releases? It seems like there is a possibility of problems in either direction.

Bug#873563: CVE-2017-11462 -- automatic sec context deletion could lead to double-free

Wait... Is that actually even legal under RFC 1964? Doesn't this lead to leaks for correctly written applications? --Sam

Bug#872056: jessie-pu: package krb5/1.12.1+dfsg-19+deb8u2

I just uploaded the jessie update after fixing the extra comma in the changelog. I did run tests covering these security updates. I found that some of the tests included in make check were already failing on jessie and were still failing after this update. It looks like this may be related to

Bug#872760: asterisk-opus: uninstallable in unstable

OK, if the checksum doesn't change regularly, I can understand why the current arrangement makes sense. It would bxe great to get asterisk-opus rebuilt though:-)

Bug#872760: asterisk-opus: uninstallable in unstable

Package: asterisk-opus Version: 13.7+20161113-3 Severity: grave Justification: renders package unusable The asterisk package in unstable provides asterisk-1fb7f5c06d7a2052e38d021b3d8ca151 but asterisk-opus depends on asterisk-fa819827cbff2ea35341af5458859233 It looks like this is a system that

Bug#871909: dgit gbp-build fails if user specifies --git-builder

> "Sean" == Sean Whitton writes: Sean> Hello, Sean> On Mon, Aug 14 2017, Ian Jackson wrote: >> There are three situations I think: >> >> 1. fetch. There is a pristine-tar branch available somewhere. >> You want to avoid downloading the

Bug#871908: dgit fails to work when .git is a reference not a directory

Hi. I tested with dgit 4.1 and it worked well enough to dgit build-source. I did not check through a full push mostly because I don't have any packages to push ATM. However if it works that well, I think it is conclusive.

Bug#871908: dgit fails to work when .git is a reference not a directory

Hi. I will check this later today once I finish catching up from debconf at $dayjob. That said: 1) I did already confirm that if you handle .git correctly, everything else works. That is, I moved the git directory to be a directory, changed .git/config to remove a no-longer-necessary override

Bug#872056: jessie-pu: package krb5/1.12.1+dfsg-19+deb8u2

(kdc crash on restrict_anon_to_tgt), , Closes: +#832572 + * fix for CVE-2016-3119: remote DOS with ldap for authenticated +attackers, Closes: #819468 + * Prevent requires_preauth bypass (CVE-2015-2694), Closes: #783557 + + -- Sam Hartman <hartm...@debian.org> Sun, 13 Aug 2017 18

Bug#871908: dgit fails to work when .git is a reference not a directory

> "Ian" == Ian Jackson writes: That bug appears to be about a case where there are submodules in the repository I give to dgit as input. My case is different. I have a super-repository of a lot of related packages with each submodule corresponding to one

Bug#871909: dgit gbp-build fails if user specifies --git-builder

package: dgit version: 3.12 What I'm really trying to do is to have dgit build my package with sbuild, checking out the pristine-tar if necessary. Why do I like that better than dgit fetch to guarantee I have the tarball? Well, perhaps I trust my local state more than the archive (I understand

Bug#871908: dgit fails to work when .git is a reference not a directory

source package libradsec dpkg-buildpackage: info: source version 0.0.5-3 dpkg-buildpackage: info: source distribution unstable dpkg-buildpackage: info: source changed by Sam Hartman <hartm...@debian.org> dpkg-buildpackage: info: host architecture amd64 fakeroot debian/rules clean dh clean --wit

Bug#871720: stretch-pu: package krb5/1.15-1

specified v4 wildcard +address; regression over previous versions, Closes: #860767 + * Fix SRV lookups to respect udp_preference_limit, regression over +previous versions with OTP, Closes: #856307 + + -- Sam Hartman <hartm...@debian.org> Wed, 09 Aug 2017 12:19:50 -0400 + krb5 (

Bug#766298: An update on trust router and release status

> "Petter" == Petter Reinholdtsen writes: >> I think shortly after the release of buster, we can close this >> bug and let moonshot-trust-router migrate into testing. Petter> Did this time arrive? Mostly. I'm working through all the moonshot software and

Bug#862051: Call for vote on allowing nodejs to provide /usr/bin/node

=== Resolution === The Technical Committee recognises that circumstances change in ways that make previous resolutions no longer appropriate. In 2012, it was resolved that the nodejs package should not provide /usr/bin/node due to the historical conflict with the ax25-node

Bug#869260: CVE-2017-11368

I can absolutely prepare a stable point update request for stretch. Is there still going to be a last point release to jessie? If so I'll look into that too; I'd definitely like to get an update in.

Bug#869260: CVE-2017-11368

Actually, on that note, why does this bug merit a DSA? It like the other bugs is a simple KDC crash from an authenticated attacker. It seems like it should be handled the same.

Bug#869260: CVE-2017-11368

Take a look at the stretch branch of git://git.debian.org/git/pkg-k5-afs/debian-krb5-2013.git Shall I upload that to stable-security?

Bug#861218: libgssapi-krb5-2: soname-independent files in shared library package (policy 8.2)

I'll remove it in purge.; there's another bug open effectively for that. However, I think it is generally a good thing if the file exists. Because of the dpkg bug we no longer install it, but I think our users are better served by leaving the file on upgrades.

Bug#868121: libgssapi-krb5-2: obsolete conffile left behind

I'm not actually sure I particularly want it removed from the system. It's fair that it should be removed on purge though and I'll at least do that.

Bug#868035: krb5: [patch]: ldap sasl auth support

Thanks for bringing this to my attention. I'll definitely fix, although I'll end up applying a somewhat different patch because of the build profiles support included in 1.15.1. SASL, like LDAP would create a cycle in stage1 builds. I expect a new version soon. I don't have a good test

Bug#866712: moonshot-gss-eap FTBFS on arm64: libeap/src/utils/common.h:429:0: error: "__bitwise" redefined [-Werror]

I'm starting the process of updating to new upstream. I think that is reasonably likely to fix this. If not, I'll look into the issue after the update. I'm OK if moonshot-gss-eap falls out of testing for a few weeks. --Sam

Bug#836127: Call for Votes for new TC member

===BEGIN The Technical Committee recommends that Niko Tyni be appointed by the Debian Project Leader to the Technical Committee. N: Recommend to Appoint Niko Tyni F: Further Discussion ===END I vote N>F signature.asc Description: PGP signature

Bug#863260: kstart: k5start does not recognize network changes

I wonder if your nss stack is somehow caching something about the network and the name servers and that kstart process is no longer able to resolve KDCs. It would be interesting to set KRB5_TRACE to a file, run kstart such that it is failing and see what specifically is not working. My bet is on

Bug#862051: Refer #862051 to ctte

> "David" == David Bremner writes: David> Philip Hands writes: >> I presume we'd want to continue providing /usr/bin/nodejs for >> people that have switched to using that, so that might as well >> continue to be the name of the binary,

Bug#861218: libgssapi-krb5-2: soname-independent files in shared library package (policy 8.2)

control: severity -1 normal Will remove this file early in buster.

Bug#861218: libgssapi-krb5-2: soname-independent files in shared library package (policy 8.2)

> "Helmut" == Helmut Grohne writes: Helmut> Package: libgssapi-krb5-2 Version: 1.15-1 Severity: serious Helmut> libgssapi-krb5-2 is a shared library package and contains Helmut> /etc/gss/mech.d/README. The latter filename does not depend Helmut> on the

Bug#860767: Failure to bind to addresses on some ipv4 only configurations

package: krb5-kdc version: 1.15-1 severity: important tags: fixed-upstream krb5-kdc can fail to work at all on some systems where getaddrinfo(NULL) returns a v6 wildcard address. Depending on kernel modules and socket configuration, you can get address family not supported even though v4 is

Bug#860520: Voting for TC Chair

> > The chair of the Debian Technical Committee will be: > > A: Keith Packard > B: Didier Raboud > C: Tollef Fog Heen > D: Sam Hartman > E: Phil Hands > F: Margarita Manterola > G: David Bremner > ===END=== I vote B > F > D > C = E = A = G signature.asc Description: PGP signature

Bug#856307: krb5-user: kinit fails for OTP user when using kdc discovery via DNS

OK. OK. If a couple of folks indicate this is an issue for them then it's a simple enough fix it could be uploaded during the stretch lifecycle.

Bug#856307: krb5-user: kinit fails for OTP user when using kdc discovery via DNS

It's almost certainly impossible to get 1.15.1 into a point release of stretch. I think though the interesting question is whether this fix should go into stretch. In general, only important or release critical fixes can be included after the freeze. When you filed this bug as normal rather than

Bug#836127: Call for Votes for new CTTE Member

> ===BEGIN > > The Technical Committee recommends that David Bremner be > appointed by the Debian Project Leader to the Technical Committee. > > A: Recommend to Appoint David Bremner > B: Further Discussion > > ===END I vote B > A My vote is not a comment on any specific candidate. As

Bug#859243: please include tmpfiles.d snippet for OTP rundir

my initial reaction is that it seems like freeipa should stick freeipa sockets in /run/freeipa not /run/krb5kdc. However, it looks like the OTP plugin in the MIT code looks at this patch although it doesn't create a socket there. Note to myself for when I look at this bug after stretch release.

Bug#858970: please add /etc/krb5.conf.d

control: -1 severity wishlist > "Timo" == Timo Aaltonen writes: Timo> Please add /etc/krb5.conf.d directory to the package and an Timo> include directive in krb5.conf so that other packages can Timo> provide snippets under the directory.

Bug#856307: krb5-user: kinit fails for OTP user when using kdc discovery via DNS

So, your experience is that with _kerberos._tcp entries but no _kerberos._udp entries it works. However, with _kerberos._udp and _kerberos._tcp entries both, it fails? If so, that's a bug. With modern (say post Windows XP), I'd imagine that TCP only will be fine. However, if adding the UDP

Bug#856307: krb5-user: kinit fails for OTP user when using kdc discovery via DNS

Do you have _kerberos._tcp DNS entries along with the _kerberos._udp entries? Does that help if not?

Bug#846002: blends-tasks must be priority:standard and not make a mess out of tasksel menu

Hi, first, you've made the point that you were hoping the TC would help the blends team and the d-i team work together. I think that Phil's suggestions for a technical approach are quite good, and I hope that will move forward in the buster cycle. With regard to stretch, I honestly don't think

Bug#846002: Call for votes on resolution for #846002 (blends-tasks)

I vote A -> FD for the blends-tasks vote. signature.asc Description: PGP signature

Bug#846002: blends-tasks must be priority:standard and not make a mess out of tasksel menu

> "Ole" == Ole Streicher writes: Georg commented that if we're going to delegate to D-I, we should hurry up and do so unless this turn into another TC failure. I personally think we've taken long enough this is already a TC failure and have expressed regret for my actions

Bug#853744: cloud-init needs net-tools

>>>>> "Marco" == Marco d'Itri <m...@linux.it> writes: Marco> On Jan 31, Sam Hartman <hartm...@debian.org> wrote: >> Why? I can understand "it would be nice if cloud-init used ip >> instead", but you seem to have a prefere

Bug#846002: blends-tasks must be priority:standard and not make a mess out of tasksel menu

>>>>> "Ole" == Ole Streicher <oleb...@debian.org> writes: Ole> Hi Sam, Am 31.01.2017 um 16:26 schrieb Sam Hartman: >> If you go back one meeting further, my interpretation is that the >> consensus of the committee seems to b

Bug#853744: cloud-init needs net-tools

> "Marco" == Marco d'Itri writes: Marco> On Jan 31, Ross Vandegrift wrote: >> Recently, net-tools was made optional. Since cloud-init does not >> depend on net-tools, this causes breakage: Marco> Please do not apply this patch! Fix

Bug#846002: blends-tasks must be priority:standard and not make a mess out of tasksel menu

> "Ole" == Ole Streicher writes: Hi. If you go back one meeting further, my interpretation is that the consensus of the committee seems to be that ultimately this decision belongs to the installer team. That is, in this case, a number of members on the TC seem to believe

Bug#853262: /usr/bin/convert: imagemagik fails to auto-detect xwd image format

Package: imagemagick-6.q16 Version: 8:6.9.7.0+dfsg-2 Severity: normal In the past, if you passed an xwd file in on stdin using a command like convert - /tmp/bar.jpg it worked. It still works if you do convert xwd:- /tmp/foo.jpg. What seems to have broken is the autodetection of xwd from file. as

Bug#852448: x11-common: ssh-agent socket removed from /tmp for long-running sessions

>>>>> "Julien" == Julien Cristau <jcris...@debian.org> writes: Julien> On 01/24/2017 03:51 PM, Sam Hartman wrote: >> Package: x11-common Version: 1:7.7+18 Severity: important >> >> Hi. In the brave new world of systemd, /tmp

Bug#852448: x11-common: ssh-agent socket removed from /tmp for long-running sessions

> "Branden" == Branden Robinson writes: Branden> Your patch looks good, except that I would quote the Branden> expansion of $XDG_RUNTIME_DIR when invoking mkdir. If Branden> $XDG_RUNTIME_DIR contains whitespace, the shell will Branden> tokenize

Bug#852448: x11-common: ssh-agent socket removed from /tmp for long-running sessions

Package: x11-common Version: 1:7.7+18 Severity: important Hi. In the brave new world of systemd, /tmp tends to get cleaned fairly aggressively even while users are logged in. I've found that after a few days my ssh agent socket gets cleaned up, and I get grumpy typing long pass phrases and

Bug#852039: [pkg-opensc-maint] Bug#852039: pam-p11: diff for NMU version 0.1.5-6.1

If your upload goes in tomorrow, it will superceed mine which will never get processed. If you miss a day, yours will still replace mine.

Bug#852039: pam_p11: crashes with tokens that require login

rescan after login. From 1392f5c0f1822e7c306ae6d9bdd3ede6f90b37c2 Mon Sep 17 00:00:00 2001 From: Sam Hartman <hartm...@debian.org> Date: Fri, 20 Jan 2017 17:24:05 -0500 Subject: [PATCH] Read certs again on token login PKCS11_login destroys all certs and keys retrieved from the token.

Bug#851628: Bugs on First CD/DVD for Jessie 8.5, 8.6, 8.7

>>>>> "Thomas" == Thomas Schmitt <scdbac...@gmx.net> writes: Thomas> Hi, Thomas> Sam Hartman wrote: >> Why do we care if it mounts on a third mac? Thomas> I care in my role as upstream of xorriso. OK. I'd ask that when interactin

Bug#851628: Bugs on First CD/DVD for Jessie 8.5, 8.6, 8.7

Why does mountability matter anyway? The interesting question is whether it boots on the target system, right? Why do we care if it mounts on a third mac?

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?

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

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

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#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: [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

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

Bug#850887: TC Involvement: MIPS and binutils

>>>>> "Lisandro" == Lisandro Damián Nicanor Pérez Meyer <perezme...@gmail.com> >>>>> writes: Lisandro> On miércoles, 11 de enero de 2017 09:39:25 ART Sam Hartman wrote: >> Hi. >> >> As you are probably aware,

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

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#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

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#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

Bug#766298: An update on trust router and release status

There was a trust router release in October. At one level, this release is probably functional enough that it would be nice to have included in stretch. At another level,there have been enough upstream bugs files that I don't think it's stable enough to include and support for the lifetime

Bug#846583: cloud.debian.org: AWS Image should enable DHCPv6 client

I've played with systemd-networkd a bit. It seems capable enough to handle this use case, but it has some significant drawbacks. It's not very backward compatible with expected sysadmin patterns. That is, as a sysadmin, I'd expect ifup and ifdown to work. I expect to be able to do things like

Bug#841294: Overrule maitainer of "global" to package a new upstream version

> "Colin" == Colin Watson writes: Colin> As a maintainer who has sometimes had cause to do similar Colin> things, I'm concerned at the standard being applied here. Colin> Could you perhaps review the history around groff 1.18.1.1 -> Colin> 1.20 for

Bug#841294: Overrule maitainer of "global" to package a new upstream version

> "Didier" == Didier 'OdyX' Raboud writes: Didier> That code is now in Debian (experimental), so yes, I do Didier> expect you to act in good faith and report bugs you see. You Didier> are obviously quite versed in how 'global' works, and that's Didier>

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

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#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#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#841294: Global Ballot Thoughts

So, does someone want to propose a resolution so we can move this forward?

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

Bug#841294: Global Ballot Thoughts

>>>>> "Ian" == Ian Jackson <ijack...@chiark.greenend.org.uk> 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

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

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

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

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#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

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

Bug#843593: Please add support for ESP partitions

Hi. I've done some more research. It turns out that being able to create an ESP partition on a bios disk label is a lot more useful than I thought it is. In the cloud space (and when I'm creating an image to be burned onto real hardware) I tend to resize the partition table and filesystems to

Bug#843593: Please add support for ESP partitions

> "Thomas" == Thomas Lange writes: Thomas> I found the thread on the linux-fai mailing list and also Thomas> the code that added efi support into setup-storage. In the Thomas> end we remove the code from FAI, since it was not needed any Thomas>

Bug#843716: Acknowledgement (setup-storage fails with fai-diskimage and btrfs)

control: tags -1 patch control: severity -1 normal Actually, the problem is somewhat simpler than that. >From e4511f8ea11c047bf19f13c7b99d9c18f8736d89 Mon Sep 17 00:00:00 2001 From: Sam Hartman <hartm...@debian.org> Date: Tue, 8 Nov 2016 18:49:38 -0500 Subject: [PATCH] Fix handling

Bug#843639: Please add EFI support

3da Mon Sep 17 00:00:00 2001 From: Sam Hartman <hartm...@debian.org> Date: Tue, 8 Nov 2016 08:42:01 -0500 Subject: [PATCH] Add GRUB_EFI class Add a class to install an EFI boot loader on a GPT-partitioned system with an ESP. Change the class misc logic not to assert GRUB_PC if GRUB_EFI i

Bug#843597: More robust capability handling

Hi. Looking at ftar in current fai, it looks like it already is fairly aggressive about using tar --xattrs for extraction. If my reading of the code is correct, this bug should probably be closed as never having been an issue. --Sam

Bug#843209: Please permit class directory-like feature for fai-diskimage

> "Thomas" == Thomas Lange writes: Thomas> Just as a short note. There's the commands fai-deps(8) which Thomas> can be used to define dependencies inside classes. It's Thomas> available in FAI but not used (means called) by default. So does the

Bug#843597: More robust capability handling

>>>>> "Thomas" == Thomas Lange <la...@informatik.uni-koeln.de> writes: >>>>> On Mon, 07 Nov 2016 17:36:41 -0500, Sam Hartman >> Currently, the sample configuration namespace has a shell script >> to restore the common capa

Bug#843597: More robust capability handling

package: fai version: 5.2 Currently, the sample configuration namespace has a shell script to restore the common capabilities found in base files; see scripts/DEBIAN/20-capabilities. This approach is brittle because as new packages in the base system gain capabilities, everyone's configuration

Bug#843593: Please add support for ESP partitions

/ 300- ext4 rw,barrier=0,noatime,errors=remount-ro tuneopts="-c 0 -i 0" >From 06a30575b8c473da89a031587debd8f6f350ba6b Mon Sep 17 00:00:00 2001 From: Sam Hartman <hartm...@debian.org> Date: Mon, 7 Nov 2016 16:41:12 -0500 Subject: [PATCH] Add support for ESP partit

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

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?

Bug#827061: Please commit to OpenSSL 1.0.2 in stretch now not constantly re-evaluateing

>>>>> "Sebastian" == Sebastian Andrzej Siewior <sebast...@breakpoint.cc> 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 re

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

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

<    1   2   3   4   5   6   7   8   9   10   >