Bug#918520: libfiu: FTBFS randomly when built with eatmydata
Hi! Have I sneakily tried to make you maintainer yet? :) one day somebody will fall for it :) Quick look at the patch looks sane, I’ll do the merge things when home and in front of the laptop with the right github credentials to do so. Sent from my iPhone > On 29 Apr 2019, at 04:25, Alberto Bertogli wrote: > >> On Sun, Apr 28, 2019 at 11:25:22AM +0200, Mattia Rizzolo wrote: >>> On Mon, Jan 28, 2019 at 05:07:34PM +, Alberto Bertogli wrote: >>> As far as I can see, this is caused by a bug/race in libeatmydata's >>> initialization, as described before. >>> >>> It is not a problem in libfiu, or its tests. >>> >>> >>> The attached patch for libeatmydata fixes the issue, but it's mostly for >>> illustration since I don't know how the maintainers would prefer to fix >>> this, and I have not tested it thoroughly (for example there's a chance of >>> infinite recursion in some very odd conditions, but it might be better to >>> leave it on purpose to ease debuggability). >> >> I fail to see those, could you maybe expand on where you think there >> could be infinite recursions? > > Looking at this again, and digging around my git repository, I think I wrote > this note based on a previous iteration of the patch. > > I think the patch in your email fixes the problems I was originally worried > about, and can't find any infinite recursion paths right now. > > Sorry for the confusion! > > Thanks! >Alberto >
Bug#730544: [debian-mysql] Bug#730544: static IV used in Percona XtraBackup
Salvatore Bonaccorso car...@debian.org writes: On Tue, Nov 26, 2013 at 12:24:34PM +0100, Thijs Kinkhorst wrote: Upstream discovered and fixed use of a static IV in encrypting backups: A fixed initialization vector (constant string) was used while encrypting the data. This opened the encrypted stream/data to plaintext attacks among others. Bug fixed #1185343. http://www.percona.com/doc/percona-xtrabackup/2.1/release-notes/2.1/2.1.6.html https://bugs.launchpad.net/percona-xtrabackup/+bug/1185343 Fixed in upstream 2.1.6. Can you please ensure that this gets into Debian? Jus a short note that a CVE was asigned now for this issue: CVE-2013-6394. I'm actively working on packaging 2.1.6 and should have packages today/tomorrow. -- Stewart Smith pgpNFdmTI4NkM.pgp Description: PGP signature
Bug#730544: [debian-mysql] Bug#730544: Bug#730544: static IV used in Percona XtraBackup
Stewart Smith stewart.sm...@percona.com writes: Salvatore Bonaccorso car...@debian.org writes: On Tue, Nov 26, 2013 at 12:24:34PM +0100, Thijs Kinkhorst wrote: Upstream discovered and fixed use of a static IV in encrypting backups: A fixed initialization vector (constant string) was used while encrypting the data. This opened the encrypted stream/data to plaintext attacks among others. Bug fixed #1185343. http://www.percona.com/doc/percona-xtrabackup/2.1/release-notes/2.1/2.1.6.html https://bugs.launchpad.net/percona-xtrabackup/+bug/1185343 Fixed in upstream 2.1.6. Can you please ensure that this gets into Debian? Jus a short note that a CVE was asigned now for this issue: CVE-2013-6394. I'm actively working on packaging 2.1.6 and should have packages today/tomorrow. I've uploaded source packages (and amd64 binaries build with sbuild locally) up to: https://flamingspork.com/junk/percona-xtrabackup-2.1.6-debian/ I'd appreciate any review/sponsor for getting them in. -- Stewart Smith pgplea3B0mcwH.pgp Description: PGP signature
Bug#718227: Packaging for Percona Playback 0.7
I have Debian packaging for the recently released Percona Playback 0.7 ready. Original upstream source tarball fetched from: http://www.percona.com/downloads/Percona-Playback-0.7/source/percona-playback-0.7.tar.gz (actually from http://www.percona.com/redir/downloads/TESTING/Percona-Playback/release-0.7/211/source/percona-playback-0.7.tar.gz but this is being moved to the above URL today-ish) I've put up the packaging at: https://flamingspork.com/junk/percona-playback-0.7/ and I've successfully built using sbuild. I'd love to have this in Debian, let me know if there's any blockers to including this in unstable. -- Stewart Smith pgp50Kd0K402E.pgp Description: PGP signature
Bug#722346: [debian-mysql] Bug#722346: Bug#722346: --no-use-db option for mysqldump?
Sébastien Hinderer sebastien.hinde...@ens-lyon.org writes: Inddeed! Actually I used --database name which I guess was expanded to --databases name, hence the USE. Rather subtle for dummy likeme... This behavior of having -- arguments expanded is deprecated in 5.6 (or 5.7, I can't remember) and will go away in a future MySQL major release. -- Stewart Smith pgpvTyfl2cnm1.pgp Description: PGP signature
Bug#718227: ITP: percona-playback -- A tool for replaying captured database server load
Package: wnpp Severity: wishlist Owner: stewart.sm...@percona.com Percona Playback is a tool for replaying the captured load of one database server against another in the most realistic way possible. Captured load can come in the form of MySQL slow query logs or tcpdump capture. It's multithreaded, modular and configurable to allow for flexibility and future extension. http://www.percona.com/doc/percona-playback/ http://www.percona.com/downloads/Percona-Playback/ Daily source packages for unstable: http://jenkins.percona.com/view/Playback/job/percona-playback-trunk-dpkg-source/debian_distribution=unstable,label_exp=sbuild/ Daily binary packages for unstable: http://jenkins.percona.com/view/Playback/job/percona-playback-trunk-dpkg/architecture=i386,debian_distribution=unstable,label_exp=sbuild/ http://jenkins.percona.com/view/Playback/job/percona-playback-trunk-dpkg/architecture=amd64,debian_distribution=unstable,label_exp=sbuild/ I'm intending to package the 0.7 release, which, since I'm in control of upstream, makes packaging for Debian easier and will incorporate any changes needed to be packaged. -- Stewart Smith pgpECmYoXg07k.pgp Description: PGP signature
Bug#718228: ITP: qpress -- Utility for manipulating quicklz archives
Package: wnpp Severity: wishlist Owner: stewart.sm...@percona.com From http://www.quicklz.com/ : QuickLZ is the world's fastest compression library, reaching 308 Mbyte/s per core. It can be used under a commercial license if such has been acquired or under GPL 1, 2 or 3 where anything released into public must be open source. - Simple to use and easy to integrate. Get done in minutes and continue developing! - Streaming mode for optimal compression ratio of small packets down to 200 - 300 bytes in size. - Auto-detection and fast treatment of incompressible data. Note: I'm working with upstream to fix a few issues with how they distribute the quicklz source that makes it a bit hard to package. -- Stewart Smith pgpAL1th0adTQ.pgp Description: PGP signature
Bug#620824: ITP: Percona XtraBackup - hot backup utility for MySQL
Hi! I'm Stewart and I work for Percona. One of the things I'm currently working on is ensuring all our free and open source software projects are packaged for all the major linux distributions - including my beloved Debian. We're wanting to have Percona XtraBackup be part of Debian. Percona XtraBackup is an online backup tool for MySQL, MariaDB, Percona Server and Percona XtraDB Cluster. In the near future, we will also wanting our packages for Percona Server and Percona XtraDB Cluster to be part of Debian. There is an open bug for Percona XtraBackup packaging: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=620824 We are going to make upload release to Debian be part of our release process. We tend to make a new minor bugfix release (i.e. 2.1.x) every 2-3 months and a new major release every 12 (2.0 in April 2012, 2.1 in May 2013). We want to be an active and involved upstream. There have been a couple of issues with our source tarballs and build procedure that I've had to fix up before proposing that Percona XtraBackup be included. I've made changes on top of our 2.1.3 release that mean we now generate source tarballs that do not require an active internet connection to build. I've put up source tarball and packaging for unstable up at: http://www.percona.com/downloads/TESTING/XtraBackup/xtrabackup-2.1.3/release-2.1.3/610/source/ All future releases will produce tarballs like this, so they'll be in a more normal area of our downloads site - I'll also get one up in an official place for the current 2.1.3 release. I (and we, the rest of Percona) would really appreciate any review/comments/suggestions on this packaging - we're really keen to have Percona XtraBackup be in the Debian archives. Why is the tarball so big and why did it require an internet connection? Well, XtraBackup uses *part* of the MySQL code (actually, mostly parts of InnoDB) to help it read InnoDB pages from disk and back them up safely. It also uses part of the code to replay REDO logs to prepare a backup before it can be restored. Due to various not-that-interesting reasons (all of which we do consider bugs) we currently produce different binaries for different MySQL versions (hence linking in code From different MySQL versions). It's important to note that we patch the InnoDB code inside MySQL to make it usable by xtrabackup and that we cannot just use the MySQL code already shipped in Debian for this without creating a nightmare for the Debian MySQL packaging team, the security team and ourselves (it's generally non-trivial to port this patch to new versions). There should never be any security implications of linking against this (not always up to date) MySQL code as we only use it to read (and write) files to local disk. Questions: 1) We have a transitional package called 'xtrabackup' that was (prior to 2.0) the package name was in our own APT repositories. Does it make sense to keep this in the Debian packaging? 2) We have trademarks. We've tried to come up with a trademark policy that makes everybody happy (well, as happy as you can be when you're dealing with trademark law). It's at: http://www.percona.com/doc/percona-xtrabackup/2.1/trademark-policy.html We believe this should satisfy any requirements of Linux distributions, but if there's any concerns, don't hesitate to ask. 3) Supported architectures. We see x86-64, x86 and very, very rarely, SPARC. I'd say that both people running XtraBackup on a non-x86 architecture are happy, but I'm pretty sure there's not even that many. While XtraBackup may compile (or even run) on other architectures, it currently makes approximately zero business sense for us to spend any time on it - although we're happy to take patches. Given this, how much works and passes tests on all archs is required to have packages accepted? 4) We plan on continuing to provide our own repositories as well and are wanting to not diverge in packaging from our repos and what's in Debian. Any tips/tricks are very welcome - we have build debian packages as part of or continuous integration efforts and plan to soon have run the whole test suite on those packages as part of it. Thanks in advance for the feedback! -- Stewart Smith pgpbTINQwmimG.pgp Description: PGP signature
Bug#620824: ITP: Percona XtraBackup - hot backup utility for MySQL
Paul Wise p...@debian.org writes: On Tue, Jul 2, 2013 at 2:41 PM, Stewart Smith wrote: I'm Stewart and I work for Percona. One of the things I'm currently working on is ensuring all our free and open source software projects are packaged for all the major linux distributions - including my beloved Debian. Since you are part of upstream, please review our upstream guide and the links in the external advice section: http://wiki.debian.org/UpstreamGuide Thanks for the pointer. It appears that we're pretty good on most things mentioned there and some things we've got plans to address. There is an open bug for Percona XtraBackup packaging: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=620824 Since you intend to package it, you should retitle this bug to intent to package and set yourself as the owner of it: http://www.debian.org/devel/wnpp/#l3 http://www.debian.org/Bugs/server-control#retitle http://www.debian.org/Bugs/server-control#owner Done. I've put up source tarball and packaging for unstable up at: http://www.percona.com/downloads/TESTING/XtraBackup/xtrabackup-2.1.3/release-2.1.3/610/source/ I'm unable to unpack the source package: $ dpkg-source -x percona-xtrabackup_2.1.3-610-1.dsc dpkg-source: warning: extracting unsigned source package (percona-xtrabackup_2.1.3-610-1.dsc) dpkg-source: error: File ./percona-xtrabackup_2.1.3-610.orig.tar.gz has size 39459 instead of expected 141074103 I'll investigate this first thing in the morning (it's getting late), although it looks as though the tar.gz didn't fully download (yes, it's really 135MB) You may want to run some commands from the source tree after a build: http://wiki.debian.org/HowToPackageForDebian#Check_points_for_any_package I think there's some good ideas here that we can add to our CI infrastructure. I don't think there's anything that would be considered a blocker though. Also, I encourage you to sign your Debian packages and also your upstream tarballs using OpenPGP keys. Here are some best practices for OpenPGP: https://we.riseup.net/riseuplabs+paow/openpgp-best-practices Yep, we typically do this. We use a key for the company rather than our individual ones for our current repositories. Is this an acceptable approach for packages going into Debian? Or should we just have the few individuals sign it if they're involved? Why is the tarball so big and why did it require an internet connection? Well, XtraBackup uses *part* of the MySQL code (actually, mostly parts of InnoDB) An alternative to including the MySQL InnoDB code might be to build-depend on mysql-source-5.5, unpack and patch it during the build process and add Built-Using: mysql-5.5 (= $version) to the resulting binary package. We'd need to depend on very specific 5.1, 5.5 and 5.6 versions of both MySQL and Percona Server (which isn't yet packaged) and we'd also have to patch it. Our short/medium term plan is to do away with having multiple server source trees and binaries. We instead plan to just make a modified MySQL branch where we just include the needed (modified) source. In an ideal world the needed code would be buildable as a library and we'd get the needed patches upstream. It is not an ideal world however :( 1) We have a transitional package called 'xtrabackup' that was (prior to 2.0) the package name was in our own APT repositories. Does it make sense to keep this in the Debian packaging? Seems reasonable to include it if you really want to. There seem to be more folks using percona-xtrabackup than xtrabackup though: I'm not really attached either way... It appears that it may not be worth having it. I'll defer to the experts on this one. 2) We have trademarks. We've tried to come up with a trademark policy that makes everybody happy (well, as happy as you can be when you're dealing with trademark law). It's at: http://www.percona.com/doc/percona-xtrabackup/2.1/trademark-policy.html We believe this should satisfy any requirements of Linux distributions, but if there's any concerns, don't hesitate to ask. I'd suggest mailing debian-legal about this question but based on the trademark policy it appears that Debian would have to rename percona if we wanted to add a security patch in stable? I'll bring it up there. We would see that as simply a patch that's needed for that version to be included in that Os and thus not an issue. You may want to listen to this FOSDEM talk entitled 'How to Share a Trademark': http://faif.us/cast/2013/may/07/0x3C/ I'll have a look. We tried to think of linux distros and Debian when we were forming the trademark policy. We'll see what Debian-legal says :) 3) Supported architectures. We see x86-64, x86 and very, very rarely, SPARC. I'd say that both people running XtraBackup on a non-x86 architecture are happy, but I'm pretty sure there's not even that many. While XtraBackup may compile (or even run) on other
Bug#620824: ITP: Percona XtraBackup - hot backup utility for MySQL
Vincent Bernat ber...@debian.org writes: ❦ 2 juillet 2013 09:20 CEST, Paul Wise p...@debian.org : Why is the tarball so big and why did it require an internet connection? Well, XtraBackup uses *part* of the MySQL code (actually, mostly parts of InnoDB) An alternative to including the MySQL InnoDB code might be to build-depend on mysql-source-5.5, unpack and patch it during the build process and add Built-Using: mysql-5.5 (= $version) to the resulting binary package. The problem is that it should Build-Depends on Percona MySQL which is not yet available in Debian. I think the first step would be to provide Percona MySQL packages. Currently, it seems that there is no easy way to provide packages as alternative to MySQL but maybe work has already started with MariaDB. It would need to build-depend on specific MySQL and Percona Server versions (which end up being on-disk compatible with various MariaDB versions). We're working on getting Percona Server ready to be included too, but we'd be going for the current Percona Server versions not the ones we patch heavily to then build XtraBackup with. But, the main problem is that we need to patch the InnoDB source to build XtraBackup and the patch isn't trivial to port to the latest versions (and there's usually no benefit in doing so). It's better to think of XtraBackup patching and including the parts of InnoDB it needs and for reasons that are largely historical it's multiple binaries for multiple versions of InnoDB. Our short/medium term goal is to stop doing this and actually just have one set of InnoDB code from the most recent MySQL/Percona Server version and one XtraBackup binary that works on all server versions. In an ideal world there'd be some library we could link against and have the patches be accepted upstream.. but we're not in an ideal world. This would make it more like something like xfsprogs which does end up including some of the same code as the kernel (although we patch InnoDB while xfsprogs seems to be about at the point where that isn't necessary). So while we do understand how it'd be great to build against the source in mysql-source-5.5, it's just not really feasible to do so and maintain quality and maintainability. We're hoping that our short/medium term of just including the patched InnoDB bits we need in our source tree to mostly solve the problem. I hope this helps clarify. -- Stewart Smith pgpVemmzIwodh.pgp Description: PGP signature
Bug#620824: ITP: Percona XtraBackup - hot backup utility for MySQL
Paul Wise p...@debian.org writes: On Tue, Jul 2, 2013 at 7:35 PM, Stewart Smith wrote: I'll investigate this first thing in the morning (it's getting late), although it looks as though the tar.gz didn't fully download (yes, it's really 135MB) Looks like your tarball is named incorrectly (tar.gz instead of orig.tar.gz) and your website returns a HTTP 302 code (redirect) and some HTML for the orig.tar.gz URL rather than a 404. I'll ensure our process includes putting the tarball up named correctly. The tarball in that directory should be the right one when named correctly though (unless I brain-farted and got it wrong :) Yep, we typically do this. We use a key for the company rather than our individual ones for our current repositories. Is this an acceptable approach for packages going into Debian? Or should we just have the few individuals sign it if they're involved? It is a reasonable approach for upstream tarballs. Uploads to Debian need to be signed by one of the keys in the developer keyring or a subkey of one of those keys. My guess is the reasonable thing to do is ensure that a few of us have keys in the keyring then so that there's some redundancy (after all, we have to let people take vacation :) We'd need to depend on very specific 5.1, 5.5 and 5.6 versions of both MySQL and Percona Server (which isn't yet packaged) and we'd also have to patch it. Our short/medium term plan is to do away with having multiple server source trees and binaries. We instead plan to just make a modified MySQL branch where we just include the needed (modified) source. In an ideal world the needed code would be buildable as a library and we'd get the needed patches upstream. It is not an ideal world however :( I see, maybe you have chosen the way of least pain. We try to :) I'm not really attached either way... It appears that it may not be worth having it. I'll defer to the experts on this one. Maybe ask your userbase if they need it? I'll reach out through our support org. I suspect we'd be fine without it. I'll bring it up there. We would see that as simply a patch that's needed for that version to be included in that Os and thus not an issue. The danger is if that approach to interpretation if the policy were to change. Okay. I'll bring it up on debian-devel and see if we need changes (it just means I probably get to talk trademark law more... which is generally something I try to avoid :) It's certainly something we may be interested at looking at... I guess we'll see what the buildds say :) We do have a test suite. It does (of course) depend on having server binaries around to run backup and restore with. Our CI infrastructure currently uses just binary tarballs of various server versions, but this probably isn't ideal for Debain so we'll have to come up with another solution. One thing to consider is that (like MySQL) running the test suite takes a non-trivial amount of time. Please do enable the test suite for Debian builds and run them with the binaries built during the build process. The problem we'll have to solve is running against MySQL (and Percona Server) versions... and I'm not sure the best way to wrangle that (we probably have to fix a bug or two in the test suite to ensure it works against an installed binary - we currently download binary tarballs and run against them). -- Stewart Smith pgpJNloePVzJP.pgp Description: PGP signature
Bug#713035: eatmydata bugs
Hi! I'm the upstream eatmydata maintainer. The aim of libeatmydata is to behave exactly the same but instead have a zero time fsync (and friends). So, if fsync(), msync() and fdatasync() are meant to be cancellation points and I can simulate that in eatmydata with calling pthread_testcancel(), I'd consider it a bug in eatmydata and with luck I'll make another upstream release today with that fixed. If you have a really short test program for it, I'll happily include it in the eatmydata test suite. Last time I checked, Debian was carrying an older eatmydata version, so it'll likely need to be updated to get this fix. -- Stewart Smith pgpUv7uzUxxpt.pgp Description: PGP signature
Bug#713035: eatmydata bugs
Thomas Preud'homme robo...@debian.org writes: And here is a proposed patch although I'm sure you don't need it :) I think we'll actually need the cancellation points before we check if eatmydata is hungry, so I'm actually going to do something slightly different than this. --- libeatmydata-26/debian/changelog 2011-02-19 13:28:02.0 +0100 libeatmydata-26 is quite old and really should be updated. Bugs fixed since then include: - added sync_file_range support - eatmydata script imported from debian, made to be cross-platform - MacOS X support - improved test suite - fixes bugs related to having/not having large file support, fixes 32bit problems - merging in most of the debian patches. so it's probably worth just updating the debian package to the newer libeatmydata. New release up at: https://launchpad.net/libeatmydata/trunk/libeatmydata-82 https://launchpad.net/libeatmydata/trunk/libeatmydata-82/+download/libeatmydata-82.tar.gz sig: https://launchpad.net/libeatmydata/trunk/libeatmydata-82/+download/libeatmydata-82.tar.gz.asc -- Stewart Smith pgptDwOPLYK87.pgp Description: PGP signature
Bug#620824: Preparing upload for 2.0.4
Hi all, We're preparing the next Percona XtraBackup release (2.0.4) currently and this is the one where we've worked on fixing lintian problems with the packaging and it should be suitable to include in Debian. As we prepare the release we'll update here. -- Stewart Smith pgpJME3S8np58.pgp Description: PGP signature
Bug#199452: Making sense of #199452
On Mon, 2008-03-03 at 00:45 -0600, John Goerzen wrote: Hi folks, I'm looking at Debian bug #199452 in OfflineIMAP. You all have reported seeing this behavior. I am not certain if this is all the same issue, as looking back over the log, it seems that in at least one case, the problem lies with the server. Since that time, major changes have occured in the IMAP code in OfflineIMAP. So I have some questions: 1) Are any of you still seeing this problem? Nope. I'm running (recent darcs) offlineimap with my patches and have since upgraded the imap server and haven't seen this problem. My guess is that one of those two things fixed it... and possibly the upgraded courier-imap. -- Stewart Smith ([EMAIL PROTECTED]) http://www.flamingspork.com/ signature.asc Description: This is a digitally signed message part
Bug#219734: Following up on #219734
On Mon, 2008-03-03 at 00:47 -0600, John Goerzen wrote: tags 219734 unreproducible thanks Hi Stewart, I'm following up on bug #219734 that you reported to OfflineIMAP. I believe that this should be better by now. If you are still seeing it, please let me know what version of OfflineIMAP you are using. Shortly, I'll do some more tests. My guess is it may have improved a bit, but not dramatically. I'll also try with and without my sqllite localstatus patch. -- Stewart Smith ([EMAIL PROTECTED]) http://www.flamingspork.com/ signature.asc Description: This is a digitally signed message part
