Bug#762659: ITP: sahara -- data-intensive application cluster (Hadoop or Spark)
Package: wnpp Severity: wishlist Owner: Thomas Goirand * Package name: sahara Version : 2014.2 Upstream Author : OpenStack Development Mailing List * URL : https://github.com/openstack/sahara * License : Apache-2.0 Programming Lang: Python Description : data-intensive application cluster (Hadoop or Spark) The Sahara project provides a simple means to provision a data-intensive application cluster (Hadoop or Spark) on top of OpenStack. It's the ex Savanna project, renamed due to potential trademark issues. -- 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/20140924083707.8156.75604.report...@buzig.gplhost.com
Re: Trimming priority:standard
Hi, > Le Tue, Sep 23, 2014 at 07:22:11PM +0200, Marco d'Itri a écrit : >> On Sep 23, Ralf Jung wrote: >> >>> I've seen multiple machines, including older machines of myself, to be >>> under full disk load for at least several minutes due to (some form of) >>> locate - every time the cronjob runs. The slowdown was noticeable, >> This is hard to believe, since the cron job uses ionice -c3. > > I had a similar experience with ‘tracker’, GNOME's equivalent of locate, which > also runs under ionice. Unfortunately I can not recall if during the years I > used the systems where the slowdown was noticeable I had changed something > relevant in the configuration of the hard drive (like running a hdparm > command) > or if it was pristine. The common thing between these machines was a loud and > slow hard drive: I never had this problem with a SSD (but again, on SSD I run > more recently installed systems where I am sure that I never used hdparm). > > Anyway, the point I want to make is that we should trust Ralf when he reports > that full disk load slows his machine despite cron jobs using ionice, although > this is probably a corner case. Just to clarify, it should be "slowed" my machine - my current machine has an SSD and no form of locate installed, all this is experience from 2 or more years ago. Since then I made sure that the experience does not repeat ;-) Kind regards Ralf -- 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/54228df7.4050...@ralfj.de
Request when replying to bugs: include the package name / topic.
This is a particularly common problem with team maintenance packages or with psuedo-packages (like release.debian.org) where a lot of people may be on the list. Please always include the package name / topic in the subject of the email or, as a matter of last resort, in the first few lines of the content of the message. I see a lot of email of the type: Subject: ping Body: Any update on this issue? EOF Umm, *which* issue? For anyone to know what is going on, it means that every subscriber has to either ignore the email or go to the bug report manually and work out which package or which type of request is being made for a pseudo-package. I know, this only goes to a subset of bug submitters and I've done this myself on occasion (and sworn at myself when I get the ack) but can people from this list *please* include something specific to the actual package/topic in the Subject of emails to bug reports? At the very least, something in the first few lines of the content saying what you are pinging? -- Neil Williams = http://www.linux.codehelp.co.uk/ signature.asc Description: PGP signature
Re: FSF and Debian join forces to help free software users find the hardware they need
Hi Neil, On Mon, Sep 08, 2014 at 04:43:03PM +0100, Neil McGovern wrote: [...] > The compatibility information comes from users testing hardware on > systems running only free software. Previously, h-node site guidelines > required they be running one of the FSF's endorsed distributions [2]. > While the FSF does not include Debian on this list because the Debian > project provides a repository of nonfree software, the FSF does > acknowledge that Debian's main repository, which by default is the only > place packages come from, is completely free. This paragraph is phrased carefully so as to make it ambiguous whether the FSF acknowledges that Debian's main repository is the only place packages come from by default. Do they? If so, it would be nice if the relevant paragraph on [1] would be updated. If not, I would still like to see some citation as to why they believe debian-installer "...in some cases recommends these nonfree firmware files for the peripherals on the machine". As I explain in [2], I don't think that's true. Thanks, [1] http://www.gnu.org/distros/common-distros.html [2] http://grep.be/blog/en/computer/debian/Is_Debian_non-free/ -- It is easy to love a country that is famous for chocolate and beer -- Barack Obama, speaking in Brussels, Belgium, 2014-03-26 signature.asc Description: Digital signature
Re: Request when replying to bugs: include the package name / topic.
On 24/09/14 11:46, Neil Williams wrote: > This is a particularly common problem with team maintenance packages or > with psuedo-packages (like release.debian.org) where a lot of people > may be on the list. > > Please always include the package name / topic in the subject of the > email or, as a matter of last resort, in the first few lines of the > content of the message. > > I see a lot of email of the type: > > Subject: ping > Body: Any update on this issue? > EOF > > Umm, *which* issue? > > For anyone to know what is going on, it means that every subscriber has > to either ignore the email or go to the bug report manually and work > out which package or which type of request is being made for a > pseudo-package. > > I know, this only goes to a subset of bug submitters and I've done this > myself on occasion (and sworn at myself when I get the ack) but can > people from this list *please* include something specific to the actual > package/topic in the Subject of emails to bug reports? At the very > least, something in the first few lines of the content saying what you > are pinging? Or even better: properly set In-Reply-To / References. You can easily do this by downloading an email from the bug thread and replying to that. Emilio -- 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/5422989b.2020...@debian.org
FSF position on non-free software and Debian (was: FSF and Debian join forces to help free software users find the hardware they need)
Wouter Verhelst writes: > This paragraph is phrased carefully so as to make it ambiguous whether > the FSF acknowledges that Debian's main repository is the only place > packages come from by default. Do they? They do, in their explanation of why Debian is not FSF endorsed. Debian's Social Contract states the goal of making Debian entirely free software, and Debian conscientiously keeps nonfree software out of the official Debian system. However, [reasons why this isn't sufficient for FSF endorsement]. https://www.gnu.org/distros/common-distros.html> > If so, it would be nice if the relevant paragraph on [1] would be > updated. I think the above – in particular, “Debian conscientiously keeps nonfree software out of the official Debian system.” – constitutes an explicit acknowledgement that Debian by default installs only free software. (For my part, I'd prefer these discussions take care to use distinct terms for the Debian Project and the operating system Debian; using the single term “Debian” for both invites confusing statements such as “Debian distributes works that are not distributed in Debian” which are rightly mocked by detractors.) > I would still like to see some citation as to why they believe > debian-installer "...in some cases recommends these nonfree firmware > files for the peripherals on the machine". As I explain in [2], I > don't think that's true. Agreed, I think you make a compelling case that “Debian recommends non-free firmware” is untrue for the installer. If there's some other part of Debian recommending non-free software, that's a bug to be identified specifically, and the current wording from the FSF doesn't help. -- \“Human reason is snatching everything to itself, leaving | `\ nothing for faith.” —Bernard of Clairvaux, 1090–1153 CE | _o__) | Ben Finney -- 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/85a95puxbr.fsf...@benfinney.id.au
Re: Request when replying to bugs: include the package name / topic.
Emilio Pozuelo Monfort writes: > Or even better: properly set In-Reply-To / References. You can easily > do this by downloading an email from the bug thread and replying to > that. Good advice. It's as easy as: $ bts show --mbox or add the ‘--mailreader=foo’ option if you want a MUA other than Mutt. -- \ “One of the most important things you learn from the internet | `\ is that there is no ‘them’ out there. It's just an awful lot of | _o__)‘us’.” —Douglas Adams | Ben Finney -- 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/8561gdux55@benfinney.id.au
Re: Request when replying to bugs: include the package name / topic.
Hi, >> Or even better: properly set In-Reply-To / References. You can easily >> do this by downloading an email from the bug thread and replying to >> that. > > Good advice. It's as easy as: > > $ bts show --mbox > > or add the ‘--mailreader=foo’ option if you want a MUA other than Mutt. or click the "Reply" link above a previous (the last?) message in the BTS web interface. Kind regards Ralf -- 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/5422a057.4000...@ralfj.de
Re: Seeking help with OpenVPN scripts and systemd
* Philipp Kern [2014-09-11 09:15]: > Not everyone uses init scripts. There is e.g. also a plugin for > network-manager, in which case it will just work. Last time I used n-m for OpenVPN it could only launch one VPN, not multiple ones. Has that changed? Tough it seems systemd upstream is not happy with n-m either as they're writing their own network management suite. Yours Martin -- 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/20140924104533.gd14...@anguilla.debian.or.at
Re: Request when replying to bugs: include the package name / topic.
Hi, [Full quote of the intitial message for the benefit of the BTS archive.] > On 24/09/14 11:46, Neil Williams wrote: >> This is a particularly common problem with team maintenance packages or >> with psuedo-packages (like release.debian.org) where a lot of people >> may be on the list. >> >> Please always include the package name / topic in the subject of the >> email or, as a matter of last resort, in the first few lines of the >> content of the message. >> >> I see a lot of email of the type: >> >> Subject: ping >> Body: Any update on this issue? >> EOF >> >> Umm, *which* issue? >> >> For anyone to know what is going on, it means that every subscriber has >> to either ignore the email or go to the bug report manually and work >> out which package or which type of request is being made for a >> pseudo-package. >> >> I know, this only goes to a subset of bug submitters and I've done this >> myself on occasion (and sworn at myself when I get the ack) but can >> people from this list *please* include something specific to the actual >> package/topic in the Subject of emails to bug reports? At the very >> least, something in the first few lines of the content saying what you >> are pinging? Or convince the BTS maintainers that #744339 is actually worth fixing (the subjects already get mangled to add the bug number one can already see in the To: field anyway, adding the package name on top or instead of it wouldn’t be such a bad move IMHO). Or educate ourselves to dig into the X-Debian-PR-Package header as advised in the bug report… Regards David signature.asc Description: OpenPGP digital signature
Re: Request when replying to bugs: include the package name / topic.
On Wed, Sep 24, 2014 at 12:32 PM, David Prévot wrote: > Or convince the BTS maintainers that #744339 is actually worth fixing > (the subjects already get mangled to add the bug number one can already > see in the To: field anyway, adding the package name on top or instead > of it wouldn’t be such a bad move IMHO). > > Or educate ourselves to dig into the X-Debian-PR-Package header as > advised in the bug report… or maybe add a "signature" as launchpad does, showing the package, the status, tags, owner, severity, title, ... -- regards, Mattia Rizzolo GPG Key: 4096R/B9444540 http://goo.gl/I8TMB more about me: http://mapreri.org Launchpad User: https://launchpad.net/~mapreri Ubuntu Wiki page: https://wiki.ubuntu.com/MattiaRizzolo -- 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/CAHKYmet-Z328Vrr6XG�po10txojwptlkaqagegrbadhrg...@mail.gmail.com
Re: Seeking help with OpenVPN scripts and systemd
On 24/09/14 11:45, Martin Wuertele wrote: > Last time I used n-m for OpenVPN it could only launch one VPN, not > multiple ones. Has that changed? Yes, I've had home and office VPNs up at the same time. (Obviously if you have more than one VPN that wants to provide the default route, or more generally a route into the same IP-range, there's going to be a conflict, probably with an arbitrarily-determined winner; but I can access two differently-numbered subnets via two different OpenVPN VPNs, and that functionality works fine.) > Tough it seems systemd upstream is not > happy with n-m either as they're writing their own network management > suite. My understanding is that they recommend NetworkManager or ConnMan (which are competitors, and fill a similar niche) for dynamic / mobile / wireless situations; whereas systemd-networkd is intended to be more like a competitor for ifupdown or equivalent, in simpler or more static situations like "my server has two network cards with static IP addresses" or "my NAS has one Ethernet socket which gets its address via dhcp". S -- 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/5422b0cf.70...@debian.org
new cowbuilder tool: make local package cache available
Hi *, I’ve just written a hookscript for pbuilder which makes the locally cached files available during a package build. Just chmod +x it, drop it into the --hookdir, and you’re set¹². Usage scenario here is mostly debian-ports: when building packages that depend on each other, you no longer have to wait until the first package is Installed until you can build the second package³. It also makes older packages, e.g. arch:all ones, available so that you can, with some APT pinning⁴, build packages against others that have temporarily become uninstallable in unstable, e.g. to break build dependency cycles. Do make sure to not put untrusted packages into the /var/cache/pbuilder/aptcache directory⁵. It does protocol all made-available packages into the pbuilder log, just so people inspecting it later can know. https://www.mirbsd.org/cvs.cgi/contrib/hosted/tg/deb/hookdir/D00local?rev=HEAD This script will be updated this week or the next, or so, because Guillem has just committed a change to dpkg that allows dpkg-scanpackages to skip generating the SHA-1 and SHA-256 hashes for the packages, so this will take only a third of the time on our slow m68k machines. (Thanks!) ① You can also share the package cache with your live system: • rm -rf /var/cache/apt/archives • ln -s /var/cache/pbuilder/aptcache /var/cache/apt/archives • echo 'Dir::Cache::Archives "/var/cache/pbuilder/aptcache";' \ >>/etc/apt/apt.conf The first two are not strictly necessary, but help e.g. scripts or people who assume the default location. Trust me. Oh, and be careful of an “apt-get clean” afterwards… ② I forgot what I wanted to write in this footnote. Maybe later… ③ Or when you upload several packages that depend on previous ones, especially when they are NEW. ④ Example paragraph (we do have current glib-networking by now): Package: glib-networking-common Pin: version 2.36.1-2~m68k.1 Pin-Priority: 1001 ⑤ Do distinguish between /var/cache/pbuilder/aptcache-debian and /var/cache/pbuilder/aptcache-ubuntu when you use my cool https://www.mirbsd.org/cvs.cgi/contrib/hosted/tg/deb/pbuilderrc?rev=HEAD Have fun, //mirabilos -- Du hast Recht. Du hast Recht! -- 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/alpine.deb.2.11.1409241440030.13...@tglase.lan.tarent.de
Re: new cowbuilder tool: make local package cache available
On Wed, 24 Sep 2014, Thorsten Glaser wrote: > Usage scenario here is mostly debian-ports: when building > packages that depend on each other, you no longer have to > wait until the first package is Installed until you can > build the second package³. It also makes older packages, Hrm. Just, there seems to be no hook for running before a cowbuilder --update so an update to, say, gcc-4.9 will not be made available, unless the resolver picks this up during B-D installation. bye, //mirabilos -- Sometimes they [people] care too much: pretty printers [and syntax highligh- ting, d.A.] mechanically produce pretty output that accentuates irrelevant detail in the program, which is as sensible as putting all the prepositions in English text in bold font. -- Rob Pike in "Notes on Programming in C" -- 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/alpine.deb.2.11.1409241554140.13...@tglase.lan.tarent.de
Bug#762697: ITP: jackson-jaxrs-providers -- Jackson JAX-RS providers
Package: wnpp Severity: wishlist Owner: Timo Aaltonen * Package name: jackson-jaxrs-providers Version : 2.4.2 Upstream Author : Tatu Saloranta * URL : http://wiki.fasterxml.com/JacksonHome * License : Apache 2.0 Programming Lang: Java Description : Jackson JAX-RS providers This is a multi-module project that contains Jackson-based JAX-RS providers for following data formats: * JSON (https://github.com/FasterXML/jackson-core) * Smile (https://github.com/FasterXML/jackson-dataformat-smile) * XML (https://github.com/FasterXML/jackson-dataformat-xml) * CBOR (https://github.com/FasterXML/jackson-dataformat-cbor) -- 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/20140924145952.28089.17011.reportbug@eldon
Re: Possible abuse of dpkg-deb -z9 for xz compressed binary packages
Hi, It's not abuse, "possible" abuse (IMO, at least :) - xz -z9 is very efficient for some cases (e.g. huge font package) - good for mirror infrastructures and low-bandwidth client On Thu, 4 Sep 2014 10:49:59 +0200 Thorsten Glaser wrote: > Such as mips? Surely it would be not comfortable for low-spec machine - but huge font packages would be installed to Desktop environment And today's average desktop has enough power, not low-spec - and it's only installation time (one time), not so harmful, IMHO It's a kind of "trade-off" issue, I choose mirror infrastructures and low-bandwidth client - so please don't regulate by system, please - lintian "info" tag is enough, IMO Of course, it's better to search "hotspot" for each package There's no perfect answer for EVERY system, our choice relies on balance for cost/profit, loss/benefit and pros/cons. Sometimes xz -z7(or 8,9) is better than -z6 (yes, sometimes), so I choose it. e.g. fonts-horai-umefont 81M data.tar 19M data.tar.xz (-6, default) 5.3Mdata.tar.xz (-9e) Obvious result: 5.3MB vs 19MB :-) As compression: - Now "Arch: All" package is built on uploaders box, so there's no hurm for buildd. - future It may hurm buildd, but use non-low performance machine would be fine. If it prevents buildd works since its compression eats mem, then we should invest more to servers, IMO. As decompression: Q: Can I install font package that was compressed with xz -z9e to low-mem machine? A: Yes, you can install fonts even if you're using low-mem machine. Probably installation is not comfartable for you and takes time, but it works. It's choice of "focus": I prefer benefit for 99% client (and mirror infrastructure). It's not best choice for lower-spec machine, but it wouldn't prevent to use it, just takes more time for only font package installation, and no performance issue on usage. -- Regards, Hideki Yamane henrich @ debian.or.jp/org http://wiki.debian.org/HidekiYamane -- 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/20140925000113.277f7675e1d29517f3d53...@debian.or.jp
Re: Request when replying to bugs: include the package name / topic.
* Emilio Pozuelo Monfort , 2014-09-24, 12:10: On 24/09/14 11:46, Neil Williams wrote: can people from this list *please* include something specific to the actual package/topic in the Subject of emails to bug reports? At the very least, something in the first few lines of the content saying what you are pinging? Or even better: properly set In-Reply-To / References. Just to clarify, In-Reply-To and References are all good, but they are not an adequate substitute for a useful mail subject. You can easily do this by downloading an email from the bug thread and replying to that. Luckily, if you do that, there's a great chance that you'll get both a helpful Subject and References. :-) -- Jakub Wilk -- 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/20140924163149.ga7...@jwilk.net
Re: Request when replying to bugs: include the package name / topic.
* David Prévot , 2014-09-24, 06:32: Or convince the BTS maintainers that #744339 is actually worth fixing (the subjects already get mangled to add the bug number one can already see in the To: field anyway, adding the package name on top or instead of it wouldn’t be such a bad move IMHO). So with #744339 fixed, you would get: Subject: release.debian.org: ping Body: Any update on this issue? EOF ...which is still not helpful. -- Jakub Wilk -- 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/20140924171054.ga3...@jwilk.net
Re: Request when replying to bugs: include the package name / topic.
On Wed, 24 Sep 2014 19:10:54 +0200 Jakub Wilk wrote: > * David Prévot , 2014-09-24, 06:32: > >Or convince the BTS maintainers that #744339 is actually worth > >fixing (the subjects already get mangled to add the bug number one > >can already see in the To: field anyway, adding the package name on > >top or instead of it wouldn’t be such a bad move IMHO). > > So with #744339 fixed, you would get: > > Subject: release.debian.org: ping > Body: Any update on this issue? > EOF > > ...which is still not helpful. > Rather than a technical solution (which would help for a lot of other packages), I'm keen on the method already mentioned here: Please use the *reply* link from the BTS for pings/updates etc. That gives a subject like: Re: Bug#745541: wheezy-pu: package virt-manager/0.600.1-3+deb7u2 Combine that with standard mailing-list filtering that everyone (should) use and then the entire message becomes: Subject: Re: pu: package policykit-1/0.105-3+deb7u1 Body: Any update on this issue? EOF That's even allowing for people to snip the entire quoted message - it is certainly reasonable to snip a lot of the quoted message as it will be the entire content but that's no different to replying to the original email sent to the bug in the first place. Of course, once someone breaks the thread and does post a "ping" subject, the reply to that post doesn't help - it's just "Re: ping?" Maybe the right fix #744339 is to use the bug title instead of the package name? Additionally, the "reply" function could always insert the bug title (it can always be edited after) instead of the subject of the previous message. -- Neil Williams = http://www.linux.codehelp.co.uk/ signature.asc Description: PGP signature
Re: Request when replying to bugs: include the package name / topic.
On Wed, 24 Sep 2014 18:30:28 +0100 Neil Williams wrote: One other idea - maybe the top level reply link (the one showing the bug number at the very top of the page) could use the current bug title as the subject of the reply rather than leaving it blank? -- Neil Williams = http://www.linux.codehelp.co.uk/ signature.asc Description: PGP signature
Re: Possible abuse of dpkg-deb -z9 for xz compressed binary packages
On 09/02/2014 09:39 PM, Henrique de Moraes Holschuh wrote: > For -z9, it is as bad as ~670MiB to > compress, and ~65MiB to decompress. I'd say this really depends on what you do. For what I do (eg: OpenStack packages), I don't see how 65MB could be a problem. I do compress with -z9, and have no intention to change this, because it makes sense for these packages, where the bottleneck for large deployments will more be the network transfers than uncompressing on each individual nodes. Thomas Goirand (zigo) -- 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/5423070b.60...@debian.org
Re: Possible abuse of dpkg-deb -z9 for xz compressed binary packages
On 09/03/2014 01:49 PM, Andrey Rahmatullin wrote: > Decompression costs were mentioned too, and they always matter I don't agree. Thomas -- 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/54230754.5000...@debian.org
Re: Possible abuse of dpkg-deb -z9 for xz compressed binary packages
On 09/04/2014 03:10 AM, Christian Kastner wrote: > Benefits: from the numbers posted in this thread, the size savings > compared to the default compression level for some sample packages are > somewhere around 3% to 4%. I claim that *practical* benefits from this > saving are insignificant to minor at best; counter-examples to this > claim are welcome. If you're doing a large deployment of a cluster, and that your bottleneck is the network and/or the mirrors, but you don't really care how fast your nodes are uncompressing, and if anyway they always have a lot of RAM, then you will effectively "win" 3 to 4% of the time needed to deploy your cluster. Now imagine that this is a big HPC system that we're talking about, and that you're paying a large amount of money to rent it, then it's well possible that 3 to 4% is a significant cost. Thomas Goirand (zigo) -- 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/54230916.90...@debian.org
Re: Possible abuse of dpkg-deb -z9 for xz compressed binary packages
On 09/04/2014 04:58 PM, Ansgar Burchardt wrote: > On 09/04/2014 10:49, Thorsten Glaser wrote: >> On Wed, 3 Sep 2014, Christian Kastner wrote: >>> That is the key question, and I believe considering the worst possible >>> cost -- a package that cannot be unpacked, as in #757740 -- the >>> trade-off is not worth it. >> >> IIRC, I asked last year already to patch dpkg to limit the >> xz compression levels to -7 (and treat -8 and -9 as -7). >> That was per-arch and mostly with buildd concerns, but this >> bugreport shows that it’s high time we do that, as those >> little 64 MiB RAM machines are available for a release >> architecture (probably several). > > A per-arch limit would not address the problem with installing arch:all > packages. > > Limiting the compression level to 7 by silently clamping higher values > is also not nice (IMO): it prevents people using very high compression > for internal packages. > > What about a lintian warning (error, whatever) instead? > > Ansgar What about more simply filling bugs for those packages where it seems inappropriate to use z9 instead of (wrongly) generalizing? :) On 09/04/2014 05:40 PM, Ondřej Surý wrote: > I support that... I don't. > lintian warning for non-default compression > lintian (auto-reject) error for > 7 Please don't do this. Cheers, Thomas Goirand (zigo) -- 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/54230a14.4050...@debian.org
Re: Possible abuse of dpkg-deb -z9 for xz compressed binary packages
On Thu, 25 Sep 2014, Thomas Goirand wrote: > On 09/02/2014 09:39 PM, Henrique de Moraes Holschuh wrote: > > For -z9, it is as bad as ~670MiB to > > compress, and ~65MiB to decompress. > > I'd say this really depends on what you do. For what I do (eg: OpenStack > packages), I don't see how 65MB could be a problem. I do compress with > -z9, and have no intention to change this, because it makes sense for > these packages, where the bottleneck for large deployments will more be > the network transfers than uncompressing on each individual nodes. OTOH, using -z9 on datasets smaller than the -z8 dictionary size *is* a waste of memory (I don't know about cpu time, and xz(1) doesn't say anything on that matter). The same goes for -z8 and datasets smaller than -z7 dictionary size, and so on. It is rather annoying that xz is not smart enough to detect this and downgrade the -z level when it is given a seekable file (which it can stat() and know the full size of beforehand). -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- 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/20140924181802.ga16...@khazad-dum.debian.net
Re: FSF position on non-free software and Debian (was: FSF and Debian join forces to help free software users find the hardware they need)
On Wed, Sep 24, 2014 at 08:28:24PM +1000, Ben Finney wrote: > Wouter Verhelst writes: > > > This paragraph is phrased carefully so as to make it ambiguous whether > > the FSF acknowledges that Debian's main repository is the only place > > packages come from by default. Do they? > > They do, in their explanation of why Debian is not FSF endorsed. > > Debian's Social Contract states the goal of making Debian entirely > free software, and Debian conscientiously keeps nonfree software out > of the official Debian system. However, [reasons why this isn't > sufficient for FSF endorsement]. > > https://www.gnu.org/distros/common-distros.html> That is not, in my opinion, an acknowledgement that main is the *only* place where packages come from *by default*. Yes, it is the only *intended* way, but that's not the same thing. > > If so, it would be nice if the relevant paragraph on [1] would be > > updated. > > I think the above – in particular, “Debian conscientiously keeps nonfree > software out of the official Debian system.” – constitutes an explicit > acknowledgement that Debian by default installs only free software. I disagree with that. In that first paragraph, they say that nonfree is not part of the official Debian system. In the second paragraph, they say that Debian's installer in some cases recommends non-free, which can be read as "making sure it gets enabled" or something along those lines. I should note that with "the relevant paragraph", I did mean the second one, i.e., the part about the installer, quoted below. > (For my part, I'd prefer these discussions take care to use distinct > terms for the Debian Project and the operating system Debian; using the > single term “Debian” for both invites confusing statements such as > “Debian distributes works that are not distributed in Debian” which are > rightly mocked by detractors.) Yeah, that makes sense. > > I would still like to see some citation as to why they believe > > debian-installer "...in some cases recommends these nonfree firmware > > files for the peripherals on the machine". As I explain in [2], I > > don't think that's true. > > Agreed, I think you make a compelling case that “Debian recommends > non-free firmware” is untrue for the installer. Thanks. > If there's some other part of Debian recommending non-free software, > that's a bug to be identified specifically, and the current wording > from the FSF doesn't help. If it's a mere bug, that would be great, because then we could fix said bug and be done with it. I suspect, however, that rather than a bug, this is a case of the (Debian) project and the FSF disagreeing on what the correct way forward is. That's fine, but it would be better if the exact disagreement could be identified; that way, either we can agree to disagree, or the project or the FSF could decide that maybe the difference in opinion isn't that big and we could reconcile our differences. The current wording doesn't make that very easy, however. -- It is easy to love a country that is famous for chocolate and beer -- Barack Obama, speaking in Brussels, Belgium, 2014-03-26 signature.asc Description: Digital signature
Bug#762725: ITP: apt-dater-host -- host helper application for apt-dater
Package: wnpp Severity: wishlist Owner: "Patrick Matthäi" * Package name: apt-dater-host Version : 1.0.0~ Upstream Author : Thomas Liske * URL : https://github.com/DE-IBH/apt-dater-host * License : GPL2+ Programming Lang: Perl Description : host helper application for apt-dater -- 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/20140924183354.3223.33184.report...@srv1.linux-dev.org
Bug#762752: ITP: pyoperators -- Operators and solvers for high-performance computing.
Package: wnpp Severity: wishlist Owner: Ghislain Antony Vaillant * Package name: pyoperators Version : 0.12.13 Upstream Author : Pierre Chanial * URL : http://pchanial.github.io/pyoperators/ * License : CeCILL-B Programming Lang: Python Description : Operators and solvers for high-performance computing. The PyOperators package defines operators and solvers for high-performance computing. These operators are multi-dimensional functions with optimised and controlled memory management. If linear, they behave like matrices with a sparse storage footprint. Compared to the existing linop package already available in Debian, this package provides more flexibility and tools for finer control of the behaviour of abstract mathematical operators. Both the linop and pyoperators packages should happily co-exist, the former providing a straightforward abstraction for quick prototyping, whilst the latter offers more advanced features such as memory management, operator properties, clever composition, etc... I believe this package would be a good fit for the mathematics-dev blend of the Debian-science project, and should be maintained by the Debian science team. -- 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/20140924220219.14365.98578.reportbug@lat6440-lap
Debugging Survey
Dear Debian Developers, since 1974 researchers and software developers try to ease software debugging. Over the last years, they created many new tools and formalized methods. We are interested if these advancements have reached professional software developers and how they influenced their approach. To find this out, we are conducting an Online Survey for Software Developers. From the results we expect new insights into debugging practice that help us to suggest new directions for future research. So if you are a software developer or know any software developers, you can really help us. The survey is, of course, fully anonymous and will take about 15 minutes to fill out. Feel free to redistribute this message to anyone who you think might be interested. The survey can be reached at: http://www.uni-potsdam.de/skopie-up/index.php/689349 Thank you for your interest, Benjamin Siegmund -- 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/cadkk7moffj2zpttqnqdx4_rdjqtbdh1ti+_d4klyxcw9p9t...@mail.gmail.com
