Re: Bug#755382: ITP: fonts-adobe-sourcehansans-cn -- “Source Han Sans CN” A sans-serif Pan-CJK font family (CN subset) that is offered in seven weights
>>>>> "PW" == Paul Wise writes: >> * Package name: fonts-adobe-sourcehansans-cn PW> Due to the need for Adobe's ADFKO, this will have to go to contrib. PW> IIRC ADFKO will become open source at some point and the font could PW> move to main then. AFAICT, fontforge has enough capability to convert the format of the files in the git repo into OTF files, at least. Pehaps also combining those into the OTC files. The outlines are in the repo as type0 (collection of type1) format, but again fontforge can edit and save that format just as well as its own sfd format, so onecan argue that it is close enough to preferred src format. So it seems they are already dfsg-free, even without a dfsg-free release of adfko, yes? Or did I miss something which fontforge and/or fonttools cannot yet accomplish? -JimC -- James Cloos OpenPGP: 0x997A9F17ED7DAEA6 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/m3siltdp0j@carbon.jhcloos.org
Re: The future of non-dependency-based boot
Three notes: Manually choosing the order remains a reasonable choice for many servers. The upstream dependencies are not always sufficiently detailed and edits to the init files can be lost when upgrading. Such servers generally start only a few services and hand-tuning the order is easy and obvious. They also typically restart less often than once per year. Systems which have had various packaged added and removed can retain legacy init scripts which prevent conversion to the new setup even where it is not unwanted. I have one long-time server on which apt-get upgrade displays a full (96x66) page dialog filled with init script which block the automated switch to dependency-based boot order. On a server which did update to dep-based I see that there are serveral S files in the default run level which shouldn't be there. They had been removed but reappeared. (Just because something is installed doesn't mean one wants it always to run.) -JimC -- James Cloos OpenPGP: 1024D/ED7DAEA6 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/m3hawlwf3v@carbon.jhcloos.org
Re: The future of non-dependency-based boot
>>>>> "PR" == Petter Reinholdtsen writes: PR> You do not have to edit the init.d files themselves to override PR> their dependencies, and risk them going away during upgrades. I PR> created the possibility for the system administrator to insert PR> overrides in /etc/insserv/overrides/ for just this use case. Good to know, Thanks. -JimC -- James Cloos OpenPGP: 1024D/ED7DAEA6 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/m3pqam7k7e@carbon.jhcloos.org
Re: Candidates for removal from testing (2013-06-30)
Humble suggestion: Sort the bug list (sort -k2 would be great) to make it easier to read through the list and to find packages which might interest one. It is a very useful report; a sort by package name would make it better. -JimC -- James Cloos OpenPGP: 1024D/ED7DAEA6 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/m338rwnt2x@carbon.jhcloos.org
tlsa for smtp to @bugs.debian.org
First of all, thanks for adding the TLSA RR for _25._tcp.buxtehude.debian.org. It is a significant step forward, even given the following. Sadly, using postfix 2.11-20130825-1 for outgoing smtp with: smtp_tls_note_starttls_offer = yes smtp_use_tls = yes smtp_dns_support_level = dnssec smtp_tls_security_level = dane If I test with: gnutls-cli --dane --local-dns --no-ca-verification --starttls --port 25 buxtehude.debian.org it connects, negotiates the tls and verifies the tlsa as expected. Without dnssec enabled in postfix's config (which consequently disables dane), the tls handshake still fails, but postfix continues on w/o tls. (It is /oportunistic/ tls, in that case.) This seems to be an openssl vs exim issue. I'm sending this here to confirm whether the @deb MXs work -JimC -- James Cloos OpenPGP: 1024D/ED7DAEA6 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/m3hadq7v5s@carbon.jhcloos.org
Re: tlsa for smtp to @bugs.debian.org
It turned out that buxtehude's exim doesn't like the (cacert-signed, wildcard) cert my box offers when sending mail. Blocking that allowed the TLS negotiation to complete, resulting in: Verified TLS connection established to buxtehude.debian.org[140.211.166.26]:25: TLSv1.2 with cipher DHE-RSA-AES256-SHA256 (256/256 bits) Most MXs, including the MX for @lists.deb, accept the cert and add a header like: Received: from ore.jhcloos.com (ore.jhcloos.com [IPv6:2604:2880::b24d:a297]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.jhcloos.com", Issuer "CA Cert Signing Authority" (not verified)) by bendel.debian.org (Postfix) with ESMTPS id 026175B for ; Thu, 12 Sep 2013 00:15:39 + (UTC) Some verify it. Buxtehude is the first so far to drop the socket as soon as it sees it. -JimC -- James Cloos OpenPGP: 1024D/ED7DAEA6 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/m3bo3y5zno@carbon.jhcloos.org
Re: tlsa for smtp to @bugs.debian.org
>>>>> "SG" == Stephen Gran writes: SG> You've confirmed that postfix can talk to postfix, at least. I SG> suppose that's a start. The debian.org MXs are different machines SG> to lists, and they run exim. Yeah. I noticed that after I sent the first note. I had checked the @deb MXs, but forgot to check @lists.deb until I saw the log. @lists's mx doesn't have a tlsa, but is signed by the deb ca (and presents that cert when sending mail, just like my outgoing box does.) Whereas the @bugs and @deb MXs have tlsa, are not signed by deb's ca, and -- according to their certs -- hang out with Luggage et alia. :) -JimC -- James Cloos OpenPGP: 1024D/ED7DAEA6 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/m3zjrh4z90@carbon.jhcloos.org
Re: tlsa for smtp to @bugs.debian.org
>>>>> "TFH" == Tollef Fog Heen writes: TFH> It's usually a good idea to mail the people who actually run the TFH> debian.org systems if you want help debugging problems like this. The first note, as I wrote, was an attempt to confirm whether the problem was limited to @bugs's MX. Given the first, it seemed only polite to explain that the issue wasn't what I thought it were. >> It turned out that buxtehude's exim doesn't like the (cacert-signed, >> wildcard) cert my box offers when sending mail. TFH> 2013-09-12 02:35:44 TLS error on connection from ore.jhcloos.com [198.147.23.85] (gnutls_handshake): The signature algorithm is not supported. TFH> I'm not entirely sure why that happens, though, given we run very TFH> similar configurations on buxthehude and the other mail-receiving hosts. Testing with: :; gnutls-cli --verbose --verbose --debug=1 --dane --local-dns \ --no-ca-verification --starttls --port 25 \ --x509certfile=/etc/ssl/certs/my_wild_cacert.pem \ --x509keyfile=my_wild.key \ buxtehude.debian.org. works fine: - Server's trusted authorities: [0]: C=NA,ST=NA,L=Ankh Morpork,O=Debian SMTP,OU=Debian SMTP CA,CN=Debian SMTP CA,EMAIL=hostmas...@puppet.debian.org [1]: C=NA,ST=NA,L=Ankh Morpork,O=Debian SMTP,OU=Debian SMTP CA,CN=Debian SMTP CA,EMAIL=hostmas...@puppet.debian.org - Successfully sent 1 certificate(s) to server. - Description: (TLS1.2-PKIX)-(RSA)-(AES-128-CBC)-(SHA1) - Session ID: D3:62:75:6A:ED:FC:C5:1C:61:12:F8:1B:06:4F:DD:81:B7:0F:9C:25:36:0C:AA:56:72:CE:9F:02:9C:E1:2C:BF - Version: TLS1.2 - Key Exchange: RSA - Client Signature: RSA-SHA256 - Cipher: AES-128-CBC - MAC: SHA1 - Compression: NULL - Channel binding 'tls-unique': 1eb70f592718d20b6721e52f Also, openssl can connect with: :; openssl s_client -CAfile /etc/ssl/certs/ca-certificates.crt \ -starttls smtp -showcerts -debug -state -crlf -tlsextdebug \ -status -msg -connect buxtehude.debian.org:25 but if I add: -key my_wild.key -cert /etc/ssl/certs/my_wild_cacert.pem it fails. The result is the same if I use a non-wild cert. But it works if I use the commercial cert I use for my https site. A cert with the same RSA size and sha1 sig hash as the cacert. So this does seem to be an openssl vs gnutls issue. I'll try to trigger it on a cloud server with debugging turned up and get a more detailed debug log. Which release does buxtehude run? Wheezy? -JimC -- James Cloos OpenPGP: 1024D/ED7DAEA6 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/m3txhp4xtl@carbon.jhcloos.org
Re: tlsa for smtp to @bugs.debian.org
>>>>> "Md" == Marco d'Itri writes: Md> Maybe it is related to this? Md> http://www.postfix.org/announcements/postfix-2.10.2.html It is related, but different. The root problem (pardon the pun) is that cacert's root certificate is signed with md5 and gnutls doesn't like that. When I use gnutls-cli to connect and submit the cert as a client cert, gnutls submits /only/ the ee cert. Openssl's s_client also sends the signing cert. When buxtehude's gnutls sees the md5-signed root cert it aborts the negotiation. The problem in the referenced URI is that gnutls refuses to tolerate a less secure DH key size. Here, gnutls refuses to tolerate a less secure hash algorithm. It should be possible to use smtp_tls_policy_maps to disable sending a client cert for the affected host(s). -JimC -- James Cloos OpenPGP: 1024D/ED7DAEA6 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/m3hado4zos@carbon.jhcloos.org
Re: tlsa for smtp to @bugs.debian.org
>>>>> "KR" == Kurt Roeckx writes: KR> A self-signed cert's signature algorithm really isn't that KR> important. You either trust that cert or you don't. Which KR> is why openssl started to ignore this for root CAs. I'm not KR> sure what gnutls does with it. Thanks. That is most reasonable. Empirically, the version of gnutls in wheezy does care about the self sig on the root cert when presented with a tls client cert chain where it (the tls server) is not configured to trust the chain's root, the root's self sig is md5 and the ee cert's sig is sha256. In this case, the tls server does not require a trusted client cert, but notes the presence of such certs. So, the ONLY think gnutls objected to in the case was that the presented client cert chain had a root-self-sig using MD5. I will send a note to gnutls-devel about it. And one to postfix-devel suggesting that if the tls nego fails just after offering a client cert, that it retry w/o the client cert. I've worked around the problem locally by offering a different cert when sending mail. -JimC -- James Cloos OpenPGP: 1024D/ED7DAEA6 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/m3bo3u1940@carbon.jhcloos.org
Re: Two new DNS virtual packages (authoritative-name-server & recursive-name-server)
As a side note to this discussion, more interesting than a list of all resolvers would be a list of /verifying/ resolvers. An easy way to find all packaged verifying resolvers, to choose one for local installation would help many users. And an easy way to depend on a local verifier would help both devs packaging 'ware which wants verified dns lookups and those reading though package deps. (Where deps includes recommends and suggests.) And a local /verifier/ is generally a more important requirement than just a local resolver. -JimC -- James Cloos OpenPGP: 1024D/ED7DAEA6 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/m3vc0nk0km@carbon.jhcloos.org
Re: -fPIE and stuff
>>>>> "RA" == Russ Allbery writes: RA> That's the main reason why I'm not sure prelinking is worth it; I'll RA> take the speed hit from using non-prelinked binaries in exchange for RA> verifiable checksums. The last time prelinking came up on the Gentoo lists, those who had done some benchmarking reported that it gave no significant benefit on amd64. I presume that also would be the case for binary dists. RA> (Of course, it would be great to have both.) To do that the prelinking has to be done when the binaries are installed, before the checksums are calculated. Ie, the package manager has to do it. -JimC -- James Cloos OpenPGP: 1024D/ED7DAEA6 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/m3sjixb6yp@carbon.jhcloos.org
Re: where is the DNSSEC root key?
When unbound is installed, the root key is at /var/lib/unbound/root.key. The init script updates it, if requsted, by way of unbound-anchor(8). Ideally there would be a separate package each dnssec-aware package could depend on which would maintain the root.key file. For comparison, gentoo has a net-dns/dnssec-root package which installs /etc/dnssec/root-anchors.txt and .xml. That would be a good precedent to follow. -JimC -- James Cloos OpenPGP: 1024D/ED7DAEA6 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/m3obkczipi@carbon.jhcloos.org
Re: Bug#706160: general: it should be easier for ordinary developers to work with Debian packages
>>>>> "CALP" == Carlos Alberto Lopez Perez writes: CALP> This can be even more simple: CALP> dh_make -f ../foo-1.tar.gz CALP> dpkg-buildpackage And where does one find dh_make? Searching on goog suggests it would be part of debhelper. But it isn't: :; dpkg -L debhelper|grep dh_make /usr/bin/dh_makeshlibs /usr/share/man/de/man1/dh_makeshlibs.1.gz /usr/share/man/fr/man1/dh_makeshlibs.1.gz /usr/share/man/man1/dh_makeshlibs.1.gz /usr/share/man/es/man1/dh_makeshlibs.1.gz :; dpkg -l|grep debhelp|perl -pe 's/ +/ /g' ii debhelper 9.20120909 all helper programs for debian/rules -JimC -- James Cloos OpenPGP: 1024D/ED7DAEA6 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/m361z8dfdr@carbon.jhcloos.org
Re: copyrighted embedded ICC profiles in images
>>>>> "JS" == Jonas Smedegaard writes: JS> I believe it does not violate DFSG to ship e.g. JFIF or GIF files JS> which was upstream distributed with copyright-protected but not JS> freely licensed ICC profiles, if repackaged to strip those ICC JS> profiles. Note that you cannot just strip colour profiles from image containers. Doing so changes the output. You'd have to replace the profile with a Free equivilent. Or, if no free equivilent is available, edit the image to match a Free profile. Such changes should be documented in the package's README.Debian, and probably in the image's metadata. -JimC -- James Cloos OpenPGP: 0x997A9F17ED7DAEA6 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/m3ha4v3sld@carbon.jhcloos.org
Re: Why not 03 ?
>>>>> "CP" == Charles Plessy writes: CP> Perhaps we can stop overriding this option ? For a lot of scientific CP> packages, -O3 is chosen by the upstream author, and I always feel bad CP> that if we make the programs slower by overriding it to -O2, it will CP> reflect poorly on Debian as a distribution for scientific works. On my gentoo box, *everything* was slower with O3. I ended up with this list, which enables the parts of O3 which do not unroll too much, and therefore do not bloat the text sections like O3: -O2 -fgcse-after-reload -ftree-partial-pre -ftree-vectorize -fpredictive-commoning -fvect-cost-model -frename-registers -floop-interchange -floop-strip-mine -floop-block The last three (-floop-*) apply only when the graphite extensions are compiled into gcc (as I do). They are no-ops otherwise. Empirically, on x86_64 at least, that is optimal. -JimC -- James Cloos OpenPGP: 0x997A9F17ED7DAEA6 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/m338fqg2wz@carbon.jhcloos.org
Re: Why not 03 ?
>>>>> "SL" == Steve Langasek writes: SL> The current default of -O2 is based on the fact that adding -O3 may give SL> worse results than -O2. On x86_64 I've yet to find anything which is slow enough to notice where moving to O3 helped. The memory pressure from the larger code segments overwhelms any benefit from reduced prediction pressure. They may exist. But I didn't find any. I only tested (or could test) on my K10. -JimC -- James Cloos OpenPGP: 0x997A9F17ED7DAEA6 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/m3wqd2eo4w@carbon.jhcloos.org
Re: linking perl statically against libperl
>>>>> "NT" == Niko Tyni writes: NT> If there are several /usr/bin/perl processes and /usr/bin/perl is NT> statically linked against libperl, every process has its own copy of NT> the libperl code in memory. But in the general case the ro pages still should be shared, yes? (Containers and the like might prevent that, but otherwise...) -JimC -- James Cloos OpenPGP: 0x997A9F17ED7DAEA6 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/m3vbgpwg7p@carbon.jhcloos.org
Re: .deb format: let's use 0.939, zstd, drop bzip2
>> I did used ar to unpack .deb several times, usually when I had to pull a file >> on a non-Debian system (or when I could not remember the dpkg-deb syntax >> and I was lazy, but that doesn’t count :) > same here. and not only this millenium, but also this decade :) ar(1) is the only thing I've ever used to look inside a deb(5) file. -JimC -- James Cloos OpenPGP: 0x997A9F17ED7DAEA6
Re: Overinterpretation of DFSG? QR code for receiving donation is non-free???
>>>>> "ST" == Samuel Thibault writes: ST> Shengjing Zhu, le lun. 30 mars 2020 15:53:18 +0800, a ecrit: >> IMO, the QR picture is preferred form of modification as well as the >> origin text. ST> Is there a program which takes a QR code, allows to modify the URL and ST> the picture in the middle, and write the new QR code with the picture? netpbm or gimp or the like along with the existing qr software should be enough. so deb almost certainly does have sufficient tools to round-trip them along with an edit to the url. -JimC -- James Cloos OpenPGP: 0x997A9F17ED7DAEA6
Re: OpenSSL 1.1.0
Is anyone keeping track of when the various packages which depend on openssl expect to upload versions compiled against 1.1? I'd like to take advantage of x25519 and chacha20-poly1305 for various tls-using servers... -JimC -- James Cloos OpenPGP: 0x997A9F17ED7DAEA6
Re: Certbot in Debian Stretch
>>>>> "PE" == Peter Eckersley writes: PE> 1. Leave Certbot out of the Debian Stretch release, and rely on PE> backports as the recommended way to run Certbot on Debian. That's what we PE> currently do with Jessie: PE> https://certbot.eff.org/#debianjessie-apache The jessie and jessie-backports releases of certbot have not, in general, been usable. There have been usable windows, but it has not been continuous. Forcing stretch uses into a similar situation would be counter-productive. -JimC -- James Cloos OpenPGP: 0x997A9F17ED7DAEA6
Re: [Letsencrypt-devel] Certbot in Debian Stretch
>>>>> "HL" == Harlan Lieberman-Berg writes: HL> Certbot has never been in jessie, so I imagine it wouldn't have been usable. Certbot, letsencrypt, python-acme, et cetera; the package name doesn't matter for this purpose. HL> I'm also haven't gotten any tickets about it being unusable. Can you HL> please provide me a link to the tickets you filed when you found it HL> unusable? There have been many threads on the vaious debian lists, so I didn't need to. And there was quite a long time when apt-get install certbot failed on jessie-backports systems due to version incompatibilities. So my main warning is that jessie-backports has failed atomically to upgrade all of the necessary components on a consistant basis, so why should we expect stretch-backports to do so? Maybe the knowledge of the issues jessie-backports has faced will be enough to ensure stretch-backports does better. Maybe. But there needs to be a pre-negotiated assurance that backports' standard procedures won't get in the way. (I understand part of the issue was update vs new for some fraction of the dependencies. Perhaps also the effect that new versions of the dependencies would have on their other reverse-dependencies?) Guaranteeing that certbot and python-acme updates will not require new dependencies probably would help on that front. -JimC -- James Cloos OpenPGP: 0x997A9F17ED7DAEA6
Re: [Letsencrypt-devel] Certbot in Debian Stretch
>>>>> "HL" == Harlan Lieberman-Berg writes: HL> In fact, letsencrypt was never in jessie either. Both certbot and HL> letsencrypt have only ever been in stable-bpo, stretch, and sid. Ok. That must have been before I was forced to switch my openvz systems from sid to jessie-backports. (The glibc maintainer broke sid, stretch and later on openvz and after it was reported refused to fix it.) But even after I was able to 'apt-get install certbot' on some of my jessie-backports machines, it was later impossible to do so on others. So there was a window where it worked followed by a long spot where it did not. HL> If you're referring to #825619, that was a bug in a dependency, not in HL> certbot, which we worked around by specifying a child version dependency HL> in python-acme. It may have been; in any case it took *weeks* for the bug I saw to get fixed. And it doesn't matter where the bug was, it still made it impossible to apt-get install the certbot package. Which still defines the certbot in jessie-backports experience as (at least historically) unreliable. Anything which takes weeks to fix is unreliable. The points I made at the end of my last note about methods which might avoid such things in the future remain on point. -JimC -- James Cloos OpenPGP: 0x997A9F17ED7DAEA6
Re: [Letsencrypt-devel] Certbot in Debian Stretch
>>>>> "HL" == Harlan Lieberman-Berg writes: HL> The fix we put in place took about ten days to hit. It shouldn't have HL> been broken longer than that; we didn't close the bug immediately, HL> because we wanted the dependency to fix their versioning. I do recall a long wait before an upload was announced, and then as you say it took too long for it to hit. I also recall that the last time I got a renewal mail and had to install certbot to do the renewal that it worked. Before that I had to use the script on the web site instead of apt to get it working on at least three machines, and I did each of them on a different week. One of those three was a renewal, two were new. And even further back it just worked. At some point I had to remove all of the acme-related packages on a couple of machines because they were blocking upgrades; once that was done a fresh install would fail due to unmatched dependencies. Beyond those details my memory of it is too fuzzy. -JimC -- James Cloos OpenPGP: 0x997A9F17ED7DAEA6
Re: [Letsencrypt-devel] Certbot in Debian Stretch
Just to be clear, my only point was, if using backports, to make certain ahead of time that whenever any changes to the packaging, including new or changed dependencies or the like, occur to always be able atomically to get the new version into backports. If conflicts are avoided then backports is fine. -JimC -- James Cloos OpenPGP: 0x997A9F17ED7DAEA6
sid on openvz
The latest glibc update breaks most sid installs on (typically leased) openvz platforms because it requires a newer kernel version that most openvz vendors advertize. Most openvz run on kernels based on 2.6.32, often with significant updates. These platforms are an important segment, given how affordable they are. And Debian "stable" is often too archaic for many needs which fit nicely on a small inexpensive server. There should be a way to continue to use sid on these platforms. Adding a hold on libc6 only causes other problems, since so much now depends on 2.21 and apt will drop them if libc6 is held on 2.19. Is there another option to avoid the breakage? -JimC -- James Cloos OpenPGP: 0x997A9F17ED7DAEA6
Re: sid on openvz
>>>>> "AJ" == Aurelien Jarno writes: AJ> If you consider Debian "stable" as too archaic, I am missing words to AJ> qualify a 2.6.32 kernel released in 2009. Prehistoric maybe? Indeed, but we don't have any choice there. And it isn't Linus' 2.6.32, its openvz's port of rh's port of 2.6.32. So it isn't as out of date as the main version number suggests. >> There should be a way to continue to use sid on these platforms. AJ> One solution is to use jessie plus backports. This will be supported up AJ> to at least May 2018, probably May 2020. I'm (slowly) switching my openvzs to that, but not being able ever to upgrade from jessie (and trusty for the U users, given that they've pulled 2.21 into xenial) is a problem, even with backports. AJ> The minimum required version in the glibc is something configurable at AJ> build time (to some extents, the absolute minimum is 2.6.32 for glibc AJ> 2.21). The ideal solution, then, would be a separate libc package compiled to work with openvz's kernel. Maybe called libc-openvz. And it would be great if apt could install it by default whenever it sees /proc/vz. This would be similar to the libc6-i686:i386, libc-xen and libc-pic packages (and any others that I missed). Given that it is already done for xen guests, it shouldn't be an issue also to do so for openvz guests. [Appologies for being slow to respond; 4.4-rc4 proved much less stable than rc3 on my workstation.] -JimC -- James Cloos OpenPGP: 0x997A9F17ED7DAEA6
