Re: Is lack of full-HD display support an RC bug?
Hi, > Looking at the description of the issue, it would also seem reasonable > to attempt to fix it in Jessie. 0.6.1-2 in jessie is not affected. It uses VNC as backend and does not implement RFX. It is slow for high resolutions, yes, but that's not this issue - it's because you haven't seen a fast VNC session at full HD either ;). 0.9.1-7 will be in jessie-backports, though. -nik -- PGP-Fingerprint: 3C9D 54A4 7575 C026 FB17 FD26 B79A 3C16 A0C4 F296 Dominik George · Hundeshagenstr. 26 · 53225 Bonn Mobile: +49-1520-1981389 · https://www.dominik-george.de/ Teckids e.V. · FrOSCon e.V. Fellowship of the FSFE · Piratenpartei Deutschland Opencaching Deutschland e.V. · Debian Maintainer LPIC-3 Linux Enterprise Professional (Security) signature.asc Description: PGP signature
Bug#855504: ITP: pyvenv-el -- Python virtual environment interface
Package: wnpp Severity: wishlist Owner: Lev Lamberov * Package name: pyvenv-el Version : 1.9 Upstream Author : Jorgen Schaefer * URL : http://github.com/jorgenschaefer/pyvenv * License : GPL-3+ Programming Lang: Emacs Lisp Description : Python virtual environment interface This is a simple global minor mode which will replicate the changes done by virtualenv activation inside Emacs. The main entry points are `pyvenv-activate', which queries the user for a virtual environment directory to activate, and `pyvenv-workon', which queries for a virtual environment in $WORKON_HOME (from virtualenvwrapper.sh).
Re: Help requested: Packages which FTBFS randomly
On Fri, Feb 17, 2017 at 06:59:00PM +, Niels Thykier wrote: > Santiago Vila: > > On Fri, Feb 17, 2017 at 06:23:00AM +, Niels Thykier wrote: > > > >> Santiago already brought it up in #844264. I believe my answer in > >> comment 70 is still relevant (other than I incorrectly used "after the > >> freeze" when I meant "after the release"). > > > > Well, but when I said "Ok, will do" in Bug #844264, it was a reply to > > your request to postpone this after the freeze, not after the release. > > > > I obviously wrote the wrong thing Actually, it was not obvious for me at all, this is what you wrote: > But I do not think we have capacity for that talk right now in the > release team (between an incomplete openssl transition and the BTS > breaking causing britney to migrate tons of packages despite RC > bugs). You mentioned here two things: openssl transition and the BTS glitch that made buggy packages to propagate to testing. Those were the "issues of the day" at the time, and are now mostly in the past. This, and the fact that no other Release Manager fixed your mistake, is the reason why I believed you meant "freeze" when you wrote "freeze". > and I am sorry for creating that misunderstanding. Ok, but please let us face the consequences: I downgraded all those bugs to important because I expected you, Release Managers, to give some guidelines about how to handle them *before* the release. If this is not going to happen, I'll have to raise those bugs to serious again, following your own guideline (see Message #35 from Julien Cristau) that the bugs are serious as a general rule (because no other guideline was given so far). If we really want to skip this issue for stretch, then we should use stretch-ignore, not severity important. Do I have your permission to use stretch-ignore here? [ I would do that on any FTBFS-randomly bug present or future, except those packages failing more than 50% of the time, because IMO that would be completely absurd ]. Thanks.
Re: Help requested: Packages which FTBFS randomly
On Wed, Feb 15, 2017 at 06:26:51PM +0100, Santiago Vila wrote: > The following packages FTBFS for me randomly. First column is the bug > number, second column is the estimated probability of failure in my > build environment, which is described here: > > https://people.debian.org/~sanvila/my-building-environment.txt Hi Santiago and everyone trying to debug these FTBFSes, For ri-li, and hopefully many of the other bugs on the list, there's a much simpler way to replicate the bug in developers' normal dev environments, using the taskset command from package util-linux to run the build on CPU #0 only: $ taskset --cpu-list 0 dpkg-buildpackage -A For ri-li, the failure can be isolated from the build: ri-li/data-src$ taskset --cpu-list 0 xvfb-run -a --server-args="-screen 0 1024x768x24" ./MakeDat Impossible d'initialiser SDL:Couldn't open X11 display Thanks, Steve
Re: Bug#848063: Help requested: Packages which FTBFS randomly
Am Sonntag, den 19.02.2017, 16:09 +0100 schrieb Steve Cotton: > Impossible d'initialiser SDL:Couldn't open X11 display Why does the package require an X11 display to build? - Fabian signature.asc Description: This is a digitally signed message part
Re: Help requested: Packages which FTBFS randomly
Ian Jackson wrote... > IMO all of these bugs should be RC. A randomly-reproducible build > failure with more than negligible probabilty is likely to show up for > some of Debian's users and downstreams and cause them mysterious > trouble. It also causes trouble for stalwarts like Santiago, doing > much needed and largely-unloved QA work. Tracking down race conditions in the build that occur every now and then only isn't joy either. At least some of the packages have the random failures in the test suite. If this justifies an RC, the maintainer will rather disable the particular test, or even the entire test suite. Something I consider the much worse scenario than having to trigger a rebuild. Random build failures do happen, for reasons inside or outside the packages. So downstream (also: security and point release builds) must be prepared for a failing build anyway. Therefore I'd rather accept random build failures, grudgingly, with the threshold set to somewhere between 5% and 10%. Rationale: Build may fail one time, the second one should very likely succeed then. > If there is to be a failure probability threshold I would set it at > 10^-4 or so. After all, computer time is cheap. To determine 10^-4 with some accurance you'd have to rebuild that package 2 times. This is an amount where computer time isn't cheap any longer. Christoph signature.asc Description: Digital signature
Bug#855530: ITP: golang-github-bsphere-le-go -- Golang library for logentries.com
X-Debbugs-CC: debian-devel@lists.debian.org, pkg-go-maintain...@lists.alioth.debian.org Package: wnpp Severity: wishlist Owner: Tim Potter * Package name: golang-github-bsphere-le-go Version : 0.0~git20170215.0.7a984a8-1 Upstream Author : Gal Ben-Haim * URL : https://github.com/bsphere/le_go * License : Expat Programming Lang: Go Description : Golang client library for logentries.com Client library for sending logs to the commercial logentries.com service. The library implements the ame methods as the Go Logger library and is also compatible with the io.Writer interface. signature.asc Description: Message signed with OpenPGP using GPGMail
Re: Help requested: Packages which FTBFS randomly
On Sun, Feb 19, 2017 at 06:27:16PM +0100, Christoph Biedl wrote: > Ian Jackson wrote... > > > If there is to be a failure probability threshold I would set it at > > 10^-4 or so. After all, computer time is cheap. > > To determine 10^-4 with some accurance you'd have to rebuild that > package 2 times. This is an amount where computer time isn't cheap > any longer. The figure by Ian is very ambitious indeed, but so much that maybe it's not very realistic. I fully agree with the underlying idea, however: If we can measure the failure rate, then it means it already fails too often to be acceptable. Anybody who tries to build all Debian source packages will find that the number of packages that fail to build is a random variable, sometimes it will be 3, sometimes it will be 5, etc. A nice goal regarding reliability would be that the expected value for this random variable (the number of failing packages) should be closer to 0 than to 1 (when you try to build once every single package). For that to happen, the around 50 packages which FTBFS randomly should do so less than 1% of the time (I'm assuming here that all the others "never" fail to build). I think this is feasible, but only if we start not allowing (i.e. making RC) things that we seem to be currently allowing. BTW: Could anybody tell me when exactly "FTBFS on a single-CPU machine" stopped being serious and RC? Did such thing ever happened? I'm pretty sure that I was already a DD when such thing could have happened, but right now I can't remember it. (See #848063 for why I'm asking this). Thanks.
Re: Help requested: Packages which FTBFS randomly
On Sun, Feb 19, 2017 at 10:59:56PM +0100, Santiago Vila wrote: > BTW: Could anybody tell me when exactly "FTBFS on a single-CPU machine" > stopped being serious and RC? Did such thing ever happened? I don't think so. (It never stopped being serious.) If some people disagree I'd say this is life and move on. (Either by escalating the bug or ignoring the bug, package & those people.) -- cheers, Holger signature.asc Description: Digital signature
Re: Help requested: Packages which FTBFS randomly
❦ 19 février 2017 22:59 +0100, Santiago Vila : > I'm pretty sure that I was already a DD when such thing could have > happened, but right now I can't remember it. > > (See #848063 for why I'm asking this). IMO, you are also pretty aggressive. More and more packages come with test suites to help developers and packagers ensure things are working as expected. It would be great if test suites didn't have failures of their own but it's better to have them and it's understandable that most packagers don't want to blindly disable them. Your chosen build environment is not common and fixing build failures for uncommon environment may seem a waste of the "Debian-allocated time" for some people (including me). The policy doesn't state that a package must build when there is not enough disk space or memory. Maybe it would be far simpler to allow packages to fail to build if there is not enough CPUs. -- Don't diddle code to make it faster - find a better algorithm. - The Elements of Programming Style (Kernighan & Plauger) signature.asc Description: PGP signature
Re: Help requested: Packages which FTBFS randomly
On Mon, Feb 20, 2017 at 12:05:42AM +0100, Vincent Bernat wrote: > More and more packages come with test suites to help developers and > packagers ensure things are working as expected. It would be great if > test suites didn't have failures of their own but it's better to have > them and it's understandable that most packagers don't want to blindly > disable them. Well, I don't advocate for doing anything "blindly", I just expect individual tests to be disabled when it's abundantly clear that they are wrongly designed. > Your chosen build environment is not common and fixing build failures > for uncommon environment may seem a waste of the "Debian-allocated time" > for some people (including me). Wait a moment. How we do define "common" when applied to a "build environment"? Number of packages built? Number of people building with such build environment? What if somebody has a build environment and builds packages 100 times as often as it's done on buildd.debian.org? Does such build environment becomes "common" then? I think it should. I would say, for example, that the build environment used by Lucas Nussbaum in his archive rebuilds, or the one in reproducible builds could easily be more "common" than buildd.debian.org, considering that the same packages are built over and over again. My own autobuilders take 7-10 days to build all packages, and they are running all the time. For Arch:all packages I build them a lot more often than buildd.debian.org, who only build them once when the maintainer uploads them, or even zero times when the maintainer does not upload in source-only form. > The policy doesn't state that a package > must build when there is not enough disk space or memory. It would not be reasonable to have a policy for that. Each package needs what it needs. I think you are comparing apples and oranges here. > Maybe it would be far simpler to allow packages to fail to build > if there is not enough CPUs. The mere concept of "not enough CPUs" is just flawed and wrong. This is basic Computer Science: Everything you can do with two or more CPUs, you can do it as well with only one CPU (even if slower). Thanks.
Re: Help requested: Packages which FTBFS randomly
On Mon, Feb 20, 2017 at 12:05:42AM +0100, Vincent Bernat wrote: > Your chosen build environment is not common and fixing build failures > for uncommon environment may seem a waste of the "Debian-allocated time" > for some people (including me). Yeah. I think your priorities are somewhat backwards: * I'd say that failing 10% of the time is way too much, and should be RC for stretch -- as someone said in this thread, there'll be expected one FTBFS in a release arch per security/stable update, and that's a practical problem. * single-CPU machines have gone the way of the dodo. Even the crummiest machine I could find while dumpster-diving looking for a non-sse3 one already has HT and builds your examples successfully. Same for ARM SoCs -- my RPi1 is kaputt, and anything newer has multiple cores. This, I'd say it's a waste of time to care about _building_ on single CPU. Meow! -- Autotools hint: to do a zx-spectrum build on a pdp11 host, type: ./configure --host=zx-spectrum --build=pdp11
Rappel : BeMyStreet devient gratuit pour les pros
BeMyStreet devient gratuit pour les pros. Nous avons une bonne nouvelle pour vous ! BeMyStreet devient gratuit pour les professionnels pour votre plus grand plaisir. Alors ne vous en privez surtout pas, vendez en ligne facilement et profitez de tous les avantages BeMyStreet : ***Visibilité*** Votre boutique apparaît dans chacune des rues de vos abonnés. ***Simplicité*** Gérez vos pages et votre vitrine simplement grâce à nos outils et nos conseils. Multipliez vos contacts* Les relations se tissent de proche en proche sur le réseau social. ***Efficacité*** Communiquez efficacement grâce à vos pages, vos actualités ou la messagerie. **Opportunité*** Avancez et sautez le pas de la vente en ligne, avec BeMyStreet c'est simple. **Aucun risque** Accédez à ce concept unique, dynamique et innovateur pour un tarif sans risque. BeMyStreet est un réseau social orienté vente en ligne sur lequel les professionnels bénéficient d'outils simples et efficaces pour être visibles, communiquer, et développer leur activité en ligne. BeMystreet se rémunère principalement sur les commissions de vente de vos produits, cela vous garantit que nous ferons toujours le maximum pour que vous vendiez vos produits ! Alors inscrivez-vous, parlez-en autour de vous et partagez... Avec la gratuité, plus aucun risque pour vous, vous avez tout à gagner... Découvrir ici : http://bemystreet.com Vous avez une question ? N'hésitez pas à nous contacter en répondant à ce mail. A tout de suite sur BeMyStreet bemystreet.com
Re: Help requested: Packages which FTBFS randomly
Vincent Bernat: > [...] > > [...] The policy doesn't state that a package > must build when there is not enough disk space or memory. Maybe it would > be far simpler to allow packages to fail to build if there is not enough > CPUs. > On a related note: Having some way to declare minimum requirements for e.g. disk space and memory (a la "base GB usage + GB usage/core") used would be great. Especially if it is available in metadata, so wanna-build can see whether it makes sense to assign a given package to a given build-node. That way we could presumably fix most of the "resource exhausted"-failures by not over-committing resources on the buildds. Thanks, ~Niels
