Re: Roll call for porters of architectures in sid and testing
Am 16.01.2014 13:31, schrieb Aníbal Monsalve Salazar: For mips/mipsel, I - fix toolchain issues together with other developers at ImgTec It is nice to see such a commitment, however in the past I didn't see any such contributions. Matthias -- To UNSUBSCRIBE, email to debian-amd64-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/52de6b8b.2060...@debian.org
Re: Roll call for porters of architectures in sid and testing
On Tue, Jan 21, 2014 at 01:43:55PM +0100, Matthias Klose wrote: Am 16.01.2014 13:31, schrieb Aníbal Monsalve Salazar: For mips/mipsel, I - fix toolchain issues together with other developers at ImgTec It is nice to see such a commitment, however in the past I didn't see any such contributions. Hello doko, At my current job, we are working on fixing mips* bugs including possible compiler errors. As an example, I recently run tests to try to find tool chain errors for packages that on non-Debian distro were failing to build. So, at least so far, I'm working on that. Regards, Aníbal signature.asc Description: Digital signature
Re: Roll call for porters of architectures in sid and testing
Hi, Just for the record. I am an active porter for the following architectures and I intend to continue this for the lifetime of the jessie release: For mips/mipsel, I - test packages on these architectures on my own machines at home and at ImgTec - fix toolchain issues together with other developers at ImgTec - triage arch-specific bugs - fix arch-related bugs - will maintain buildds I am a DD. Aníbal Monsalve Salazar signature.asc Description: Digital signature
Re: How to get a new palo source package into unstable?
Hello Helge! On Sat, Jan 11, 2014 at 10:37:52PM +0100, Helge Deller wrote: as you might have noticed, we did huge progress on the HPPA (PA-RISC) port: http://buildd.debian-ports.org/stats/ Indeed. Congratulations on that! I'm glad to see the HPPA port coming back to life. I'd love to test it myself, but the only PA-RISC machine that I currently know of which is in my vicinity is located inside a laboratory at my physics department and it's still running HP-UX. Might be that it gets scrapped soon and replaced with something more fancy so that I can get hold of it, who knows ;). In order to be able to boot parisc machines, the hppa port needs the palo debian package. PALO is the PA-RISC boot loader and a boot-loader-image generator, similar to lilo on i386 or silo on sparc. Or aboot on the Alpha machines. I've continued to maintain and further develop palo. The new palo git repository is now at: git://git.kernel.org/pub/scm/linux/kernel/git/deller/palo.git and the source should compile and run on all plattforms. A simple checkout and dpkg-buildpackage should work. Thank you very much for doing this (and the hard work of bringing the buildds back to life). Even though I currently don't own a PA-RISC machine, I'm very glad that someone took care of it, such that owners of these machines can still use it with a current Debian release. Since I'm not a debian-developer, I don't know how to get this package into debian unstable again. What is the usual process to get a new/old package back into debian unstable? Maybe someone of you who has a debian developer rights is willing to upload the source package? I'm a Debian Developer with full upload permissions to the archive and would absolutely love to help you get the boot loader (and any other possibly necessary packages) back into Debian. The best is to have the package(s) uploaded to Debian Mentors [1] so I can grab them from there and review them, send you suggestions on improving them and finally upload them. Plus, it would be nice to have access to a PA-RISC machine myself so I can perform a test build and inspect the finished package. Would that be possible? PS: I have noticed that the HPPA builds never include the build log, for example radeontop [2]. Would it be possible to have these enabled as well, so we can easily find out what went wrong when a build failed? Cheers, Adrian [1] http://mentors.debian.net/ [2] http://buildd.debian-ports.org/status/package.php?p=radeontopsuite=sid -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 -- To UNSUBSCRIBE, email to debian-amd64-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20140112163248.ga10...@physik.fu-berlin.de
Re: How to get a new palo source package into unstable?
Hi Helge! On 01/12/2014 10:36 PM, Helge Deller wrote: Indeed. Congratulations on that! I'm glad to see the HPPA port coming back to life. I'd love to test it myself, but the only PA-RISC machine that I currently know of which is in my vicinity is located inside a laboratory at my physics department and it's still running HP-UX. Might be that it gets scrapped soon and replaced with something more fancy so that I can get hold of it, who knows ;). Good thing is, that those machines got pretty cheap now. A Dualcore-C8000 workstation is available on ebay for 100 EUR. If just had enough room. There are already too many Amigas taking up my space :). Still, I like to support the port as much as I can. I'm a Debian Developer with full upload permissions to the archive and would absolutely love to help you get the boot loader (and any other possibly necessary packages) back into Debian. Thanks! AFAIK the bootloader is the only package which is parisc specific. Ok, good to know. The best is to have the package(s) uploaded to Debian Mentors [1] so I can grab them from there and review them, send you suggestions on improving them and finally upload them. I uploaded it, and CC'ed you on the request. http://mentors.debian.net/package/palo The info at top of the website is the latest package with most warnings fixed. It would be nice if you could help me (off-list) further on that. Will do! I'll answer your separate mail later! Plus, it would be nice to have access to a PA-RISC machine myself so I can perform a test build and inspect the finished package. Would that be possible? Sure, I'll send you login details off-list. If other people here on the list want access, please let me know. Thanks, got them. Will change the password and install my SSH key ASAP. We had problems with sending mails from the buildds when I started the buildds mid december. Currently we have 5 buildds running: http://unstable.buildd.net/index-hppa.html Since around 2-3 weeks, all buildds except mx3210 do send build logs. Ah, glad to hear it has been fixed. Then there's nothing I am worrying about. Are you working together with Ingo Juergensmann to update the buildd status information on buildd.net? I can reschedule a rebuild of radeontop for you, or you can just build it yourself on the machine for which I send you a login. Just let me know. Don't worry about radeontop. I just picked that package as an example to check whether the build logs are still missing or not. This is one of my own packages and the last upload was just done a few weeks ago, so I thought I might check this one to see whether the problem has already been addressed. But when you say the logs are properly uploaded now, I'm happy. So, please don't reschedule the package, it will updated in the very near future anyway. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 -- To UNSUBSCRIBE, email to debian-amd64-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/52d33683.2020...@physik.fu-berlin.de
How to get a new palo source package into unstable?
Hello everyone, as you might have noticed, we did huge progress on the HPPA (PA-RISC) port: http://buildd.debian-ports.org/stats/ In order to be able to boot parisc machines, the hppa port needs the palo debian package. PALO is the PA-RISC boot loader and a boot-loader-image generator, similar to lilo on i386 or silo on sparc. palo has been part of the debian repository when parisc was still a fully-supported debian architecture, but was dropped when debian 6.0 was released. I've continued to maintain and further develop palo. The new palo git repository is now at: git://git.kernel.org/pub/scm/linux/kernel/git/deller/palo.git and the source should compile and run on all plattforms. A simple checkout and dpkg-buildpackage should work. Since I'm not a debian-developer, I don't know how to get this package into debian unstable again. What is the usual process to get a new/old package back into debian unstable? Maybe someone of you who has a debian developer rights is willing to upload the source package? Any help would be great! Thanks, Helge Deller -- To UNSUBSCRIBE, email to debian-amd64-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/52d1b9b0.3010...@gmx.de
gcc-4.9 uploaded to experimental
gcc-4.9 is uploaded to experimental, asking the porters to watch for build failures and corresponding patches. See https://buildd.debian.org/status/package.php?p=gcc-4.9suite=experimental These are already fixed in the vcs. - fixed the gospec.c ftbfs on archs without ld.gold - fixed the g++ b-d on armel/armhf Matthias -- To UNSUBSCRIBE, email to debian-amd64-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/52cfd843.1010...@debian.org
Re: maintainer communication
On Mon, Dec 23, 2013 at 10:59 PM, Finn Thain fth...@telegraphics.com.au wrote:
Why is CONFIG_SERIAL_PMACZILOG to be disabled? And why was
See the discussion in the thread before this message.
I've seen no discussion of this on debian-68k or linux-m68k. What
discussion are you referring to?
The subject of this thread (before you shortened it) was maintainer
communication (was Re: Debian kernel regression, was Re: Modernizing a
Macintosh LC III).
That discussion covered both the usefulness of the serial console (i.e.
CONFIG_SERIAL_PMACZILOG) and the problematic disappearance of
CONFIG_EARLY_PRINTK.
I guess it's about the crash on non-Mac when passing debug=serial.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say programmer or something like that.
-- Linus Torvalds
--
To UNSUBSCRIBE, email to debian-amd64-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.org/CAMuHMdVDH9Jw979gU=+GVCdwXzDFww+tNFY=pmd4fkpmfaq...@mail.gmail.com
maintainer communication (was Re: Debian kernel regression, was Re: Modernizing a Macintosh LC III)
Dixi quod… Hi $maintainer, can we still get CONFIG_EARLY_PRINTK=y and CONFIG_SERIAL_PMACZILOG=n into 3.12 before it hits unstable? This was, of course, not integrated into src:linux before the 3.12.6-1 upload. (Which by the way autobuilt, meaning we have build logs ☻ instead of me building it in cowbuilder manually on a – possibly faster – VM.) The request to the GCC maintainer to somehow make autoconf regenerate some more configure scripts, to fix the -fpic/-fPIC problem, was, of course, also not integrated. I think we need to file bugs in the BTS for each of these instances in the future, instead of trying to communicate with the maintainers directly. I hate it, because I like to talk to humans more, and some people on the Debian side hate it too (“because debports is not Debian”), but… *shrug*. Tell me if you have a better idea. Or anything else to comment on this matter. To clarify: this is *not* intended to make package maintainers show in a bad light, rather the contrary, trying to improve things. I can understand that things that are not in the BTS are likely to be forgotten (in fact I forgot a suggestion how to do/fix something too, due to falling ill last week and not writing it down e.g. in the bug). Thanks, //mira“still on antibiotics but recovering”bilos -- diogenese Beware of ritual lest you forget the meaning behind it. igli yeah but it means if you really care about something, don't ritualise it, or you will lose it. don't fetishise it, don't obsess. or you'll forget why you love it in the first place. -- To UNSUBSCRIBE, email to debian-amd64-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/pine.bsm.4.64l.1312231011210.24...@herc.mirbsd.org
Re: maintainer communication
Finn Thain dixit: Why is CONFIG_SERIAL_PMACZILOG to be disabled? And why was See the discussion in the thread before this message. CONFIG_EARLY_PRINTK disabled? It was never enabled. And that’s what you get when you let a BSD guy whose Linux experience dates back to 2.0.3[3-6] (and some 2.4.3) do the Debian/m68k Linux kernel config, instead of someone who actually knows about this. I did warn y’all back then. Now we got a config, and we can incrementally improve it. how it can help when it is downstream of the kernel developers. Eh? Parse error. bye, //mirabilos -- „Also irgendwie hast du IMMER recht. Hier zuckelte gerade ein Triebwagen mit der Aufschrift Ostdeutsche Eisenbahn durch Wuppertal. Ich glaubs machmal nicht…“ -- Natureshadow, per SMS „Hilf mir mal grad beim Denken“ -- Natureshadow, IRL, 2x -- To UNSUBSCRIBE, email to debian-amd64-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/pine.bsm.4.64l.1312231645470.2...@herc.mirbsd.org
Re: maintainer communication
Hi, On Mon, Dec 23, 2013 at 04:47:30PM +, Thorsten Glaser wrote: Finn Thain dixit: Why is CONFIG_SERIAL_PMACZILOG to be disabled? And why was See the discussion in the thread before this message. I am not sure which thread you are meaning, and in general, I think discussing random Linux kernel config options on -ports is off-topic. Maybe you sent the initial mail to the wrong list? Michael -- To UNSUBSCRIBE, email to debian-amd64-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20131223170941.gg4...@raptor.chemicalconnection.dyndns.org
Re: maintainer communication
On Mon, 23 Dec 2013, Thorsten Glaser wrote: Finn Thain dixit: Why is CONFIG_SERIAL_PMACZILOG to be disabled? And why was See the discussion in the thread before this message. I've seen no discussion of this on debian-68k or linux-m68k. What discussion are you referring to? The subject of this thread (before you shortened it) was maintainer communication (was Re: Debian kernel regression, was Re: Modernizing a Macintosh LC III). That discussion covered both the usefulness of the serial console (i.e. CONFIG_SERIAL_PMACZILOG) and the problematic disappearance of CONFIG_EARLY_PRINTK. CONFIG_EARLY_PRINTK disabled? It was never enabled. Yes it was. See Modernizing a Macintosh LC III: http://lists.debian.org/debian-68k/2013/11/msg00070.html Finn -- To UNSUBSCRIBE, email to debian-amd64-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/alpine.LNX.2.00.1312240849320.18824@nippy.intranet
Re: maintainer communication
Michael Banck dixit: I am not sure which thread you are meaning, and in general, I think discussing random Linux kernel config options on -ports is off-topic. Indeed, that wasn’t the intent of this thread. I’ve continued that particular discussion on debian-68k. My intent in _this_ thread was to get a discussion among debian-ports.org users started for best practices of how to communicate with package maintainers in Debian. Sorry for being unclear there. I had hoped for hints ☺ since I know my communication skills lack somewhat. bye, //mirabilos -- emacs als auch vi zum Kotzen finde (joe rules) und pine für den einzig bedienbaren textmode-mailclient halte (und ich hab sie alle ausprobiert). ;) Hallo, ich bin der Holger (Hallo Holger!), und ich bin ebenfalls ... pine-User, und das auch noch gewohnheitsmäßig (Oooohhh). [aus dasr] -- To UNSUBSCRIBE, email to debian-amd64-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/pine.bsm.4.64l.1312232212380.2...@herc.mirbsd.org
Re: debootstrap and debian-ports
Michael Schmitz dixit: your finding that packages from both unstable and unreleased are needed is correct (along with the complication that some may not be availabe at any given time). There’s another problem: even in the main Debian archive, “unstable” is *not* guaranteed to be debootstrap’able, and has regularily been broken. Good news for m68k though: eglibc, gcc-4.8 and linux are no longer in “unreleased”. In fact: tg@freewrt:~ $ u=/var/lib/apt/lists/ftp.de.debian.org_debian-ports_dists_unreleased_main_binary-m68k_Packages tg@freewrt:~ $ # test idempotency tg@freewrt:~ $ grep-dctrl -r -P . $u | diff -u - $u | wc 0 0 0 tg@freewrt:~ $ # get me all source packages that have packages in unreleased/m68k tg@freewrt:~ $ grep-dctrl -r -P . -n -s Source:Package $u | sort -u atari-bootstrap atari-fdisk gcc-4.6 gcj-4.6 glib-networking gnat-4.6 google-gadgets libbluray m68k-vme-tftplilo m68kboot mesa mysql-5.1 vmelilo webkit We can group them by: • architecture-specific packages atari-bootstrap atari-fdisk m68k-vme-tftplilo m68kboot vmelilo • architecture-specific patches, packages going away in sid soon anyway gcc-4.6 gcj-4.6 gnat-4.6 mysql-5.1 (actually already gone) • maintainer refuses integrating our patches libbluray (maybe ping again?) mesa(refusal also upstream) • patches need to be updated against current versions of the packages google-gadgets (waits on webkit/gtk) webkit • “Build without libproxy, for bootstrapping.” glib-networking None of them is, however, strictly needed for debootstrap (although the architecture-specific packages may be needed when d-i’ing a system). I read somewhere that Aurélien regularily creates snapshots of debian-ports – which means that we can install m68k from these, Right Now™. deb http://ftp.debian-ports.org/debian-snapshot/2013-12-12/ unstable main This should work. Maybe Aurélien can “freeze” one of these, if needed? -- Back to debootstrap. Yes, it needs support for multiple versions (already has some, atm) and the unreleased distribution right now. I guess APT’s ordering (from a given package, always use the dpkg-numerically largest version, ignoring all dpkg-numerically smaller versions, period) would work for now, as we don’t have the arch:all/arch:any mix in the minbase, base or buildd set much (except libsemanage-common). Everything else needs a very complicated solver (such as, use an older libsemanage-common that works with the libsemanage1 version in the archive) and is out of scope for the sh-based debootstrap. bye, //mirabilos (short, caught the flu) -- mirabilos│ untested Natureshadow │ tut natürlich Natureshadow │ was auch sonst ... mirabilos│ fijn ☺ -- To UNSUBSCRIBE, email to debian-amd64-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/pine.bsm.4.64l.1312181709050.19...@herc.mirbsd.org
Re: debootstrap and debian-ports
jhcha54008 dixit: Custom mini-repositories for installation - One may download the missing packages from http://snapshot.debian.org/archive/debian-ports. Indeed, but – as I said – the regular debian-ports archive is also weekly snapshotted, and Aurélien can persist them TTBOMK (like etch-m68k was). I’ve got a manually created mini-repository for m68k, but experience shows acceptance of these is questionable even if done by a DD, *and* you need custom archive keys, so I think it’s best to stick to “more official” ways if these contain all needed packages in unstable (or debootstrap’s patched to handle unreleased). bye, //mirabilos -- Using Lynx is like wearing a really good pair of shades: cuts out the glare and harmful UV (ultra-vanity), and you feel so-o-o COOL. -- Henry Nelson, March 1999 -- To UNSUBSCRIBE, email to debian-amd64-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/pine.bsm.4.64l.1312182157360.19...@herc.mirbsd.org
Re: debian-ports.org getting relatively unstable (hppa)
Helge Deller dixit:
We noticed, that when we manually binmnu-upload packages, which are
already in the *same version* on debian-ports, then debian-ports ACCEPT
When you binNMU packages you add a +b1, +b2, … suffix to their
versions. ITYM porter upload?
those packages, but if we then try to apt-get-update those later on, this leads
to a size mismatch error. I do have the feeling, that this is a
problem on debian-ports.
I noticed this problem too, when I accidentally built a package
I already had uploaded (and totally forgotten about): basically,
the new *.deb files are accepted but the Packages file still
contains the checksums etc. from the old *.deb file.
Only way to fix this is to reupload the old *.changes file, or
to do a binNMU proper. Or to build a newer version, ofc…
So, I'm anxious, that if I start the buildd, it will happily build and upload
packages
which we already uploaded to debian-ports. If this happens we will get more
size-mismatch errors.
That’s what you have wanna-build for. Basically, stop doing
manual uploads without wanna-build locking at least six hours
before turning on the first buildd. After that time, when you
want/need to build a package manually, lock it in wanna-build:
either “take” it for building, or mark as N-F-U.
See here for more info on that:
• https://wiki.debian.org/M68k/Porting#binNMU_notes
• http://lists.debian.org/debian-68k/2012/12/msg00124.html
• http://lists.debian.org/debian-68k/2013/10/msg00021.html
If you have packages that buildds should never build, for example
like we had gcc-4.{6,8} for some time, mark them as Not-For-Us;
otherwise, just take them for building.
deller@leda:~$ wb info hello . hppa
This the same as “wanna-build -A hppa -d unstable --info hello”.
But on http://ftp.debian-ports.org/debian/pool-hppa/main/h/hello/ you can
see, that the hello-package is already uploaded at version 2.8-4
Indeed. This is bad, new, another / a different problem, and we
didn’t have this on m68k. (Note that uploads usually take a bit
until they show up on w-b, hence the need for locking.)
So, if my buildd now uploads the newly created hello package, I'm sure
we will run again into the size-mismatch problem.
Yes, you will definitely run into that problem when you upload
hello_2.8-4_hppa again.
My question here on the list would be, if you (other arch-porters) do have an
idea
on how I should proceed.
Either…
Best solution would probably be, if the wanna-build database rescans what's in
the archive already. Is this possible?
… that (no idea if it’s possible), or make two lists: a list of what
is currently in the archive for hppa, and a list of packages in the
Needs-Build or BD-Uninstallable¹ state. Then, for every package in
the same versions (except +b* sufficēs) in *both* lists, schedule a
binNMU (e.g. to get hello_2.8-4+b1_hppa). Do note whether it already
got a binNMU suffix: e.g. aclock.app_0.2.3-3+b4 would need to be
scheduled for --binNMU=5 to be larger.
You might be able to cheat, e.g. take hello for building, then tell
it that you uploaded it. But I don’t know why w-b doesn’t register
that it’s there in the first place, so a rescan, if possible, should
happen first.
Hm, only 12 packages here:
tg@leda:~$ wanna-build -A hppa -d unstable --list=needs-build | less
But this has more (9043):
tg@leda:~$ wanna-build -A hppa -d unstable --list=bd-uninstallable | less
① You need to include BD-Uninstallable because they will happily
convert to Needs-Build once you upload e.g. perl.
Or, should I just start the buildd and see what's happening? If we then get
No, get the w-b list consistent first.
According to
http://ftp.debian-ports.org/debian/dists/unstable/main/binary-hppa/Packages.bz2
hello is at version 2.8-4 just fine… hmm. So the apt-ftparchive database
seems to be correct.
This is all quite complicated, so feel free to ask around when we
can help you out again, no need for every arch to go through all
of this by themselves, figure out best practices again, etc.
HTH HAND,
//mirabilos
--
If Harry Potter gets a splitting headache in his scar
when he’s near Tom Riddle (aka Voldemort),
does Tom get pain in the arse when Harry is near him?
-- me, wondering why it’s not Jerry Potter………
--
To UNSUBSCRIBE, email to debian-amd64-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.org/pine.bsm.4.64l.1312151335210.21...@herc.mirbsd.org
Re: debian-ports.org getting relatively unstable (hppa)
Hi, On Sun, Dec 15, 2013 at 11:54:43AM +0100, Helge Deller wrote: On 12/15/2013 06:32 AM, Dave Land wrote: Not sure what's up at debian-ports.org, but I've been trying to debootstrap 2 different HPPA machines for the last couple days and have been getting a variety of errors (size mismatches, files not found when they were there 20 minutes before, etc. etc.) Somebody may want to look into this before it gets out of hand. Thanks! :) I maybe should add some more background here, and maybe someone here on the list might have an idea on how to proceed. Background is, that Dave and myself have binmnu-uploaded the necessary packages for hppa so that debootstrap worked. Then we proceeded with the necessary packages for sbuild and schroot, so that I now have a buildd installed which should be able to start building packages. I haven't turned it on yet though for the reasons which I explain in a few seconds... In the meantime we have of course uploaded a few more packages which now currently break debootstrap. This is fixable manually, but I instead of uploading packages manually now, I would prefer to get the buildd going instead... So, Dave Land, please wait a little bit... Now to the reasons why I didn't turned on the buildd yet: We noticed, that when we manually binmnu-upload packages, which are already in the *same version* on debian-ports, then debian-ports ACCEPT those packages, but if we then try to apt-get-update those later on, this leads to a size mismatch error. I do have the feeling, that this is a problem on debian-ports. I noticed for example that reprepro usually doesn't accept packages of the same version which doesn't seem to be the case on debian-ports. This is indeed the case, apt-fptarchive keep the checksums corresponding to first package. That said it hasn't really caused any problem so far. So, I'm anxious, that if I start the buildd, it will happily build and upload packages which we already uploaded to debian-ports. If this happens we will get more size-mismatch errors. Well if you leave the build daemons handling the uploads, they will not build and upload the same package again, and the problem won't happen. A trivial example: On machine buildd.debian-ports.org I run: deller@leda:~$ wb info hello . hppa * hello/hppa | hello: | Package : hello | Version : 2.8-4 | State : Needs-Build | Section : devel | Priority: source | Previous-State : | State-Change: 2013-02-18 00:03:36.782007 | CalculatedPri : 52 | component : main | Distribution: sid | Notes : out-of-date | State-Days : 300 | State-Time : 25958430 So, the package hello would need a rebuild according to the wanna-build database, and that would wb probably tell my buildd who then would start building/uploading it. But on http://ftp.debian-ports.org/debian/pool-hppa/main/h/hello/ you can see, that the hello-package is already uploaded at version 2.8-4 So, if my buildd now uploads the newly created hello package, I'm sure we will run again into the size-mismatch problem. The wanna-build database is not up to date on hppa. I have disabled it to save some very precious cpu cycles given there are no buildds on hppa yet. Now, Aurelien mentioned last week to me, that this size-mismatch error might be because of the apt-ftparchive cache might have been corrupted for hppa. I'm not 100% sure about that. Ok I wasn't aware the same package have been uploaded multiple time, so the corruption comes clearly from there. My question here on the list would be, if you (other arch-porters) do have an idea on how I should proceed. I would say stop doing manual upload and start the build daemons. Best solution would probably be, if the wanna-build database rescans what's in the archive already. Is this possible? Yes, I can re-enable the hppa wanna-build database if it is actually useful. Or, should I just start the buildd and see what's happening? If we then get the size-mismatch errors there is lot of manual work to fix it (unless resetting the apt-ftparchive on debian-ports would solve this). We can rebuild the apt-ftparchive database at some point. Aurelien -- Aurelien Jarno GPG: 1024D/F1BCDB73 aurel...@aurel32.net http://www.aurel32.net -- To UNSUBSCRIBE, email to debian-amd64-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20131215200337.ga2...@hall.aurel32.net
Re: debian-ports.org getting relatively unstable (hppa)
Hi Thorsten,
thanks for your help!
On 12/15/2013 02:59 PM, Thorsten Glaser wrote:
Helge Deller dixit:
We noticed, that when we manually binmnu-upload packages, which are
already in the *same version* on debian-ports, then debian-ports ACCEPT
When you binNMU packages you add a +b1, +b2, … suffix to their
versions. ITYM porter upload?
Yes, we did correct binNMU uploads for packages which already existed
in the same version in the repo. But there were lots of packages which
were outdated (the hppa build servers stopped in 2011!) and for those
we just rebuilt from current source and uploaded with the current
version.
those packages, but if we then try to apt-get-update those later on, this
leads
to a size mismatch error. I do have the feeling, that this is a
problem on debian-ports.
I noticed this problem too, when I accidentally built a package
I already had uploaded (and totally forgotten about): basically,
the new *.deb files are accepted but the Packages file still
contains the checksums etc. from the old *.deb file.
Ok, so it's a generic problem.
Only way to fix this is to reupload the old *.changes file, or
to do a binNMU proper. Or to build a newer version, ofc…
Yes, this is how we solved it too (binNMU) then.
So, I'm anxious, that if I start the buildd, it will happily build and
upload packages
which we already uploaded to debian-ports. If this happens we will get more
size-mismatch errors.
That’s what you have wanna-build for. Basically, stop doing
manual uploads without wanna-build locking at least six hours
before turning on the first buildd. After that time, when you
want/need to build a package manually, lock it in wanna-build:
either “take” it for building, or mark as N-F-U.
Ok.
See here for more info on that:
• https://wiki.debian.org/M68k/Porting#binNMU_notes
• http://lists.debian.org/debian-68k/2012/12/msg00124.html
• http://lists.debian.org/debian-68k/2013/10/msg00021.html
Good links. Thanks!
If you have packages that buildds should never build, for example
like we had gcc-4.{6,8} for some time, mark them as Not-For-Us;
otherwise, just take them for building.
deller@leda:~$ wb info hello . hppa
This the same as “wanna-build -A hppa -d unstable --info hello”.
But on http://ftp.debian-ports.org/debian/pool-hppa/main/h/hello/ you can
see, that the hello-package is already uploaded at version 2.8-4
Indeed. This is bad, new, another / a different problem, and we
didn’t have this on m68k. (Note that uploads usually take a bit
until they show up on w-b, hence the need for locking.)
It seems the wb-database was turned off because we didn't had buildd
servers for quite some time. Aurelien will turn it back on again.
So, if my buildd now uploads the newly created hello package, I'm sure
we will run again into the size-mismatch problem.
Yes, you will definitely run into that problem when you upload
hello_2.8-4_hppa again.
My question here on the list would be, if you (other arch-porters) do have
an idea
on how I should proceed.
Either…
Best solution would probably be, if the wanna-build database rescans what's
in
the archive already. Is this possible?
… that (no idea if it’s possible), or make two lists: a list of what
is currently in the archive for hppa, and a list of packages in the
Needs-Build or BD-Uninstallable¹ state. Then, for every package in
the same versions (except +b* sufficēs) in *both* lists, schedule a
binNMU (e.g. to get hello_2.8-4+b1_hppa). Do note whether it already
got a binNMU suffix: e.g. aclock.app_0.2.3-3+b4 would need to be
scheduled for --binNMU=5 to be larger.
You might be able to cheat, e.g. take hello for building, then tell
it that you uploaded it. But I don’t know why w-b doesn’t register
that it’s there in the first place, so a rescan, if possible, should
happen first.
Before Aurelien's answer I was thinking if this could work on leda too:
touch -d2013-01-01 ~/ref
cd /srv/mini-dak/ftp/debian/pool-hppa/main
find . -newer ~/ref | grep .changes$
Basically it would just try to find all packages (.changes) which
we uploaded after january 2012. Then in the next step maybe use the
--pretend-avail option of wb to tell it that this package is already
up-to-date. Not sure if this would work though...
But I will now first wait until the wb-database will gets activated
again and check then.
Hm, only 12 packages here:
tg@leda:~$ wanna-build -A hppa -d unstable --list=needs-build | less
But this has more (9043):
tg@leda:~$ wanna-build -A hppa -d unstable --list=bd-uninstallable | less
① You need to include BD-Uninstallable because they will happily
convert to Needs-Build once you upload e.g. perl.
Or, should I just start the buildd and see what's happening? If we then get
No, get the w-b list consistent first.
Ok.
According to
http://ftp.debian-ports.org/debian/dists/unstable/main/binary-hppa/Packages.bz2
hello is at version 2.8-4 just fine…
Bug#731261: transition: Qt5 switching qreal == double for all platforms
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition Note: people receiving this mail through the arm/ports/pkg-kde-talk mailing list: please reply to the bug. Hi everyone! First of all please bare with me and try to read the whole mail before replying. This might look like a hairy thing, but we Qt maintainers think that there is a chance of making things better and easier for all of us in the future. As you may know Qt has a typedef [DISCLAIMER] named qreal which is defined as double for almost all archs except arm* (and specifically for Debian, sh4), where is it bound to float. While in Qt4 this will still be valid, in Qt5 (not yet shipped in any Debian stable release nor available as a backport) upstream changed qreal to be double on all platforms by default, adding a compile-time switch to be able to change it's value if needed. That sounds really good, except for the fact that this will happen in 5.2.0... without a SONAME bump. We could easily just use the switch in the appropiate archs and be done. Yes, this could simply work but we think there is a chance to make things better with some little effort from us. But first let's try to enumerate what are the benefits and downsides of doing this. Suppose for a moment we set qreal to double for all archs. This would mean: - And ABI change (either with/without SONAME bump, see later) - Less porting problems like [PORT], thus easier code/transitions. - Possibly better real handling in all archs, even if that might mean a slow down for some things. I can push rc1 to experimental with qreal=double for all archs if you want to test (or some other place if someone can provide the bandwith). - No slow down for OpenGL stuff: this part of the Qt5 API has been written explicitely with float. - We already have ARM hardware with hard float support and it wouldn't surprise me this will get more common and faster in the following years, and this is a decisition which would expland all over Qt5's life span, which we could expect to be at least 10 years from now judging from Qt3/Qt4 experience. Now let's analyse Qt5's current situation on Debian: - It currently has, appart from the ~14 source packages that make the Qt5 stack and needs a sourcefull upload, 4 reverse dependencies, one being the python Qt5 bindings and three apps. - It has never been shipped on a Debian stable release nor in backports. So we are left with the SONAME bump thing. We Qt maintainers consider that trying to be somehow binary compatible with other distros is a worthwhile goal. Of course, this includes not bumping the SONAME. I've called other distro's maintainers in Qt's devel ML [QTMSG] with little feedback and over IRC to Fedora and OpenSuse people. Over Fedora lands, one Qt maintainer told me they where going to push the ABI change without SONAME bump while an ARM maintainer cried for a SONAME bump. I had no reply from OpenSuse. I have also asked to the Ubuntu guys, but I sincerely forgot if they are waiting to see what we are going to do, switch without soname bump or doing more tests, and I left my logs at my other PC :-( So we think the best thing we could do is, for this very exceptional case, set qreal to double on all archs and break ABI on arm* and sh4, which could be fixed by [bin]NMUing the three apps that currently build-depend against it (I think python's bindings will need a sourcefull upload too). Now I want to be *clear* that if not bumping the SONAME is not a solution then I'll simply keep armel, armhf and sh4 with qreal=float and be done. So I would like what the RT and arm* porters thinks. As a complementary note, Qt 5.2.0's release is expected around christmas. Thanks a lot for reading, Lisandro. [DISCLAIMER] I'm clerly not in the position of making this typedef go away, so please don't insist with this. [PORT] http://lists.alioth.debian.org/pipermail/pkg-kde-talk/2013-November/001855.html [QTMSG] http://lists.qt-project.org/pipermail/development/2013-November/014017.html -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 3.10-3-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to debian-amd64-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20131203180918.7215.8716.report...@dumbledore.dumbledore.com.ar
Re: Bug#731261: transition: Qt5 switching qreal == double for all platforms
On Tue, Dec 03, 2013 at 03:09:18PM -0300, Lisandro Damián Nicanor Pérez Meyer wrote: Now I want to be *clear* that if not bumping the SONAME is not a solution then I'll simply keep armel, armhf and sh4 with qreal=float and be done. Why is bumping the SONAME a problem? Isn't it there just to handle API changes? -- hendrk -- To UNSUBSCRIBE, email to debian-amd64-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20131204004055.gb19...@topoi.pooq.com
Re: A new metric for source package importance in ports
Hi,
Quoting Steven Chamberlain (2013-11-28 01:04:56)
On 27/11/13 17:58, Johannes Schauer wrote:
http://mister-muffin.de/p/Gid8.txt
One can see that now the amount of source packages which is needed to build
the
rest of the archive is only 383.
So, there are 383 packages that share the same, maximum value (in this
case 11657) in the second column?
Correct.
$ curl -s http://mister-muffin.de/p/Gid8.txt | awk '{ if ($2==11657) print $0
}' | wc -l
383
In this particular graph the maximum value of the second column (11657) is less
than the total amount of source packages (in contrast to the first graph)
because this latter graph assumes that arch:all, essential:yes and
build-essential do not have to be rebuild. Therefore, lots of source packages
do not have to be compiled at all.
Does anybody see enough value in these numbers for source package
importance in the light of bootstrapping Debian (either for a new port or
for rebuilding the archive from scratch)?
I find the list of 383 packages interesting, at least. I think this
closure is what I had in mind[0] for regular testing of ports' toolchains and
reproducibility of builds.
In that email you wrote:
Some people have been trying to identify small sets of essential packages
already, in the context of bootstrapping an architecture[1]. I wonder if
that's likely to overlap with this? It encompasses toolchain and essential
arch-specific packages.
I imagine a healthy port should be able to bootstrap itself with only current
package versions. If this was being tested regularly it could let porters
know if circular dependencies are introduced
Yes, if you omit the necessity to rebuild arch:all packages, then these 383
source packages are about what you were talking about: the set of source
packages which makes a port able to bootstrap itself. Though notice that this
number (383) is only the very lower bound because it was deducted using strong
dependencies only. You can see the upper bound in the column that was
calculated using the closure graph which would be 457 source packages.
If you also want to rebuild arch:all packages, then you have to look at the
first graph and then the number quickly climbs to 1194 source packages minimum
and 1424 source packages maximum.
Does the list vary by architecture? I see many odd things in here such as
'systemd' and 'redhat-cluster' which would be unavailable if trying to
bootstrap a non-Linux port, for example.
Yes it does vary by architecture because dependencies can have architecture
qualifiers. Here, I used amd64 as an example.
I also find it interesting to see openjdk-7 listed but not gcj; or even
gcc-4.8. Was this computed for jessie or sid?
Using Debian Sid as of yesterday.
cheers, josch
--
To UNSUBSCRIBE, email to debian-amd64-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20131128080012.2752.32993@hoothoot
Re: A new metric for source package importance in ports
Hi, Quoting Dmitrijs Ledkovs (2013-11-28 01:15:06) On 28 November 2013 00:04, Steven Chamberlain ste...@pyro.eu.org wrote: I also find it interesting to see openjdk-7 listed but not gcj; or even gcc-4.8. Was this computed for jessie or sid? I guess implicit relationships are not considered: build-essential build-dependencies, and essential dependencies. I would expect for packages in those to sets have the highest rank, since, hypothetically, all packages in debian build-depend depend on those. Steven was looking at the second graph which (in contrast to the first graph) makes the assumption that essential:yes and build-essential are already available somehow (for example by having cross compiled them) and thus do not need to be recompiled to bootstrap the port. gcj and gcc-4.8 is part of the packages which are drawn in by creating a co-installation set of essential:yes and build-essential packages. Therefore they do not appear in the second graph. Since this co-installation set is an input to the algorithm of creating the second graph, they implicitly receive the highest rank. For the same reason you will also see them being assigned the highest rank in the first graph which does not assume that essential:yes and build-essential do not have to be recompiled. Implicit dependency relationships are considered by both algorithms to calculate the strong dependencies and the dependency closure of source and binary packages. My code uses dose3 to do the required calculations. cheers, josch -- To UNSUBSCRIBE, email to debian-amd64-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20131128080700.2752.98455@hoothoot
A new metric for source package importance in ports
Hi, the following is a report of a successful implementation of what I have been talking about with Niels Thykier during debconf13. The question was how important it is for a source package to be compilable or exist in the first place given an incomplete port which is in the process of being bootstrapped. This work is solving a different purpose than the identification of key packages by Lucas Nussbaum [1]. Instead of attaching a binary value to each source package, this method is associating integer values to them. Once bootstrapping of the whole archive becomes more important or even possible in real life through an implementation of build profiles, this heuristic could be used to further extend the meaning of key packages as well. This heuristic attaches to each source package A the number of source packages which need A to be compilable so that they become compilable themselves. The dependency graph which is needed to extract this information is conveniently created by the service I run as http://bootstrap.debian.net - I'm using a simple Python script to walk this graph to extract the information. In fact that Python script uses two different graphs. Since dependencies contain disjunctions, there exists different choices for packages which have to be available for something to be compilable or installable. To not make this choice arbitrary, I calculate the minimum number of dependencies that have to be available (strong dependencies) and the maximum number that has to be available (dependency closure). Therefore each source package A is associated with two numbers: the minimum amount of source packages which depend on A being compilable and the maximum number of source packages which depend on A being compilable. To create more than syntactic meaning I also added popcon information to the output. I associate to each source package A the sum of all popcon values of the source packages which depend on A being compilable. Again this is done for the minimum as well as the maximum. So here is the (tab delimetered) data in no particular order: http://mister-muffin.de/p/pVxb.txt 1st column: the name of the source package 2nd column: minimum number of source packages which need this source pacage to be compilable 3rd column: maximum number of source packages which need this source pacage to be compilable 4th column: minimum sum of popcon values 5th column: maximum sum of popcon values Do you see any obvious error? When sorting the data by the second column, you will see that there are 1194 source packages with the same value: 19554. This value corresponds to the total amount of source packages. It means: everything else depends on these 1194 source packages being compilable. If those 1194 source package are not compilable then the rest will be neither. Remember that this only true during a bootstrappping scenario. These 1194 source package are also all part of the same strongly connected component of the strong srcgraph and roughly correlate to the smallest set of packages which are needed for a self-hosting Debian system. We call a set of binary and source packages self-hosting if all binary packages can be created from the source packages and all source packages can be compiled with just the available binary packages. In my opinion it would make sense to make all packages which are at minimum required to make Debian self-hosted to the set of key packages by extending the definition by Lucas Nussbaum at [1]. The amount of source packages which are needed to bootstrap themselves and all the rest of Debian is that high because it includes source packages which are only included because of the arch:all binary packages they build, because of the essential:yes packages they build or because of the build-essential packages they build. While it is important to include these for rebuilds of the whole archive, they are not important in a real bootstrap situation. Arch:all binary packages already exist and do not need to be bootstrapped and to start to compile packages natively, a minimal build system (essential:yes + build-essential) is required in the first place. Therefore I created a different graph which takes into account that arch:all packages as well as the packages of the minimal build system do not need to be rebuild: http://mister-muffin.de/p/Gid8.txt One can see that now the amount of source packages which is needed to build the rest of the archive is only 383. It is important that these source packages remain compilable (in addition to essential:yes + build-essential being cross-able) because otherwise a bootstrap of any new architecture cannot be done. The service at http://bootstrap.debian.net will indicate that an architecture is not bootstrappable at all if this is the case. Does anybody see enough value in these numbers for source package importance in the light of bootstrapping Debian (either for a new port or for rebuilding the archive from scratch)? If so, then I can generate these
Re: A new metric for source package importance in ports
Hi josch! On 27/11/13 17:58, Johannes Schauer wrote: http://mister-muffin.de/p/Gid8.txt One can see that now the amount of source packages which is needed to build the rest of the archive is only 383. So, there are 383 packages that share the same, maximum value (in this case 11657) in the second column? Does anybody see enough value in these numbers for source package importance in the light of bootstrapping Debian (either for a new port or for rebuilding the archive from scratch)? I find the list of 383 packages interesting, at least. I think this closure is what I had in mind[0] for regular testing of ports' toolchains and reproducibility of builds. Because each Debian port depends in some indirect way on the authenticity of these packages. And likewise any toolchain bugs are most critical here. I just didn't think there would be so many packages. Does the list vary by architecture? I see many odd things in here such as 'systemd' and 'redhat-cluster' which would be unavailable if trying to bootstrap a non-Linux port, for example. I also find it interesting to see openjdk-7 listed but not gcj; or even gcc-4.8. Was this computed for jessie or sid? [0]: http://lists.debian.org/5266df9d.9040...@pyro.eu.org Regards, -- Steven Chamberlain ste...@pyro.eu.org -- To UNSUBSCRIBE, email to debian-amd64-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/529688a8.8080...@pyro.eu.org
Re: A new metric for source package importance in ports
Johannes Schauer wrote: Hi, the following is a report of a successful implementation of what I have been talking about with Niels Thykier during debconf13. The question was how important it is for a source package to be compilable or exist in the first place given an incomplete port which is in the process of being bootstrapped. This work is solving a different purpose than the identification of key packages by Lucas Nussbaum [1]. Instead of attaching a binary value to each source package, this method is associating integer values to them. Once bootstrapping of the whole archive becomes more important or even possible in real life through an implementation of build profiles, this heuristic could be used to further extend the meaning of key packages as well. One problem with these metrics is that you get source packages whose importance is artifically inflated because of the way our source packages work. If anything in a source package needs x then the whole source package has to build-depend on x. Even if x is only needed for some perhipheral functionlity that could easilly be removed in the event that x was unavailable (either on a particular port or in general). In the case of libraries there may be a binary dependency too for rarely used fuctionality. For example some of the mesa libraries drag in libwayland0 which means wayland ends up with a very high importance even though afaict hardly anyone uses it right now. Another big example is languages. Lots of packages build language bindings for lots of languages dragging those languages into the important set. So these metrics are a good guide to what packages are unimportant but to determine whether a package is really important or just psuedo-important still requires human judgement. -- To UNSUBSCRIBE, email to debian-amd64-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/52968a89.6050...@p10link.net
Re: A new metric for source package importance in ports
On 28 November 2013 00:04, Steven Chamberlain ste...@pyro.eu.org wrote: Hi josch! On 27/11/13 17:58, Johannes Schauer wrote: http://mister-muffin.de/p/Gid8.txt One can see that now the amount of source packages which is needed to build the rest of the archive is only 383. So, there are 383 packages that share the same, maximum value (in this case 11657) in the second column? Does anybody see enough value in these numbers for source package importance in the light of bootstrapping Debian (either for a new port or for rebuilding the archive from scratch)? I find the list of 383 packages interesting, at least. I think this closure is what I had in mind[0] for regular testing of ports' toolchains and reproducibility of builds. Because each Debian port depends in some indirect way on the authenticity of these packages. And likewise any toolchain bugs are most critical here. I just didn't think there would be so many packages. Does the list vary by architecture? I see many odd things in here such as 'systemd' and 'redhat-cluster' which would be unavailable if trying to bootstrap a non-Linux port, for example. I also find it interesting to see openjdk-7 listed but not gcj; or even gcc-4.8. Was this computed for jessie or sid? I guess implicit relationships are not considered: build-essential build-dependencies, and essential dependencies. I would expect for packages in those to sets have the highest rank, since, hypothetically, all packages in debian build-depend depend on those. Regards, Dmitrijs. -- To UNSUBSCRIBE, email to debian-amd64-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CANBHLUiifmR+_keS3eSQa_b3_CfZ_56o9vBRR8p2SeY=hy9...@mail.gmail.com
Re: A new metric for source package importance in ports
Instead of dwelling on this discovery, which is not productive, why not concentrate on what to do to improve Debian. The analysis has shown faults. Has Debian stopped working? Has the world crashed? The problems have been identified, the patches to address the issues are being evaluated and planned for retesting. By January 15,2014, Debian, Ubuntu , SUSE13.1, Fedora, RedHat, and probably every distribution that has an old or recent kernel will be corrected. So, whats the next topic? Regards Leslie Mr. Leslie Satenstein An experienced Information Technology specialist. Yesterday was a good day, today is a better day, and tomorrow will be even better.lsatenst...@yahoo.com SENT FROM MY OPEN SOURCE LINUX SYSTEM. From: Dmitrijs Ledkovs x...@debian.org To: Steven Chamberlain ste...@pyro.eu.org Cc: Johannes Schauer j.scha...@email.de; Debian Release debian-rele...@lists.debian.org; debian-po...@lists.debian.org Sent: Wednesday, November 27, 2013 7:15 PM Subject: Re: A new metric for source package importance in ports On 28 November 2013 00:04, Steven Chamberlain ste...@pyro.eu.org wrote: Hi josch! On 27/11/13 17:58, Johannes Schauer wrote: http://mister-muffin.de/p/Gid8.txt One can see that now the amount of source packages which is needed to build the rest of the archive is only 383. So, there are 383 packages that share the same, maximum value (in this case 11657) in the second column? Does anybody see enough value in these numbers for source package importance in the light of bootstrapping Debian (either for a new port or for rebuilding the archive from scratch)? I find the list of 383 packages interesting, at least. I think this closure is what I had in mind[0] for regular testing of ports' toolchains and reproducibility of builds. Because each Debian port depends in some indirect way on the authenticity of these packages. And likewise any toolchain bugs are most critical here. I just didn't think there would be so many packages. Does the list vary by architecture? I see many odd things in here such as 'systemd' and 'redhat-cluster' which would be unavailable if trying to bootstrap a non-Linux port, for example. I also find it interesting to see openjdk-7 listed but not gcj; or even gcc-4.8. Was this computed for jessie or sid? I guess implicit relationships are not considered: build-essential build-dependencies, and essential dependencies. I would expect for packages in those to sets have the highest rank, since, hypothetically, all packages in debian build-depend depend on those. Regards, Dmitrijs. -- To UNSUBSCRIBE, email to debian-amd64-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CANBHLUiifmR+_keS3eSQa_b3_CfZ_56o9vBRR8p2SeY=hy9...@mail.gmail.com
Re: A new metric for source package importance in ports
Hi, Quoting peter green (2013-11-28 01:12:57) One problem with these metrics is that you get source packages whose importance is artifically inflated because of the way our source packages work. If anything in a source package needs x then the whole source package has to build-depend on x. Even if x is only needed for some perhipheral functionlity that could easilly be removed in the event that x was unavailable (either on a particular port or in general). In the case of libraries there may be a binary dependency too for rarely used fuctionality. For example some of the mesa libraries drag in libwayland0 which means wayland ends up with a very high importance even though afaict hardly anyone uses it right now. Another big example is languages. Lots of packages build language bindings for lots of languages dragging those languages into the important set. So these metrics are a good guide to what packages are unimportant but to determine whether a package is really important or just psuedo-important still requires human judgement. Correct. The situation can be greatly improved once build profiles allow to mark build dependencies as less important or non essential. cheers, josch -- To UNSUBSCRIBE, email to debian-amd64-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20131128074506.2752.10616@hoothoot
Re: Bug#730258: please add arch-specific BTS tags
On 24/11/2013 02:45, Robert Millan wrote: On 23/11/2013 22:53, Don Armstrong wrote: kfreebsd-amd64 kfreebsd-i386 Most of the bugs affecting one of these also affect the other. I think it makes sense to add a single tag to cover both. FWIW, I think dpkg resolved this quite nicely by splitting the architecture in two: $ head -n 9 ostable cputable | grep -v ^# == ostable == uclibceabi-linuxlinux-uclibceabilinux[^-]*-uclibceabi uclibc-linuxlinux-uclibclinux[^-]*-uclibc gnueabihf-linux linux-gnueabihf linux[^-]*-gnueabihf gnueabi-linux linux-gnueabi linux[^-]*-gnueabi gnuspe-linuxlinux-gnuspelinux[^-]*-gnuspe gnux32-linuxlinux-gnux32linux[^-]*-gnux32 gnulp-linux linux-gnulp linux[^-]*-gnulp gnu-linux linux-gnu linux[^-]*(-gnu.*)? gnu-kfreebsdkfreebsd-gnukfreebsd[^-]*(-gnu.*)? gnu-knetbsd knetbsd-gnu knetbsd[^-]*(-gnu.*)? gnu-kopensolariskopensolaris-gnukopensolaris[^-]*(-gnu.*)? gnu-hurdgnu gnu[^-]* bsd-darwin darwin darwin[^-]* bsd-freebsd freebsd freebsd[^-]* bsd-netbsd netbsd netbsd[^-]* bsd-openbsd openbsd openbsd[^-]* sysv-solarissolaris solaris[^-]* uclibceabi-uclinux uclinux-uclibceabi uclinux[^-]*-uclibceabi uclibc-uclinux uclinux-uclibc uclinux[^-]*(-uclibc.*)? tos-mintmintmint[^-]* == cputable == i386i486(i[3456]86|pentium) 32 little ia64ia64ia6464 little alpha alpha alpha.* 64 little amd64 x86_64 x86_64 64 little armeb armeb arm.*b 32 big arm arm arm.* 32 little arm64 aarch64 aarch64 64 little avr32 avr32 avr32 32 big hppahppahppa.* 32 big m32rm32rm32r32 big m68km68km68k32 big mipsmipsmips(eb)? 32 big mipsel mipsel mipsel 32 little powerpc powerpc (powerpc|ppc) 32 big ppc64 powerpc64 (powerpc|ppc)64 64 big s390s390s39032 big s390x s390x s390x 64 big sh3 sh3 sh3 32 little sh3eb sh3eb sh3eb 32 big sh4 sh4 sh4 32 little sh4eb sh4eb sh4eb 32 big sparc sparc sparc 32 big sparc64 sparc64 sparc64 64 big -- Robert -- To UNSUBSCRIBE, email to debian-amd64-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/5291e6ef.4020...@gmx.com
Re: Bug#730258: please add arch-specific BTS tags
On Sat, 23 Nov 2013, Ivo De Decker wrote: During a discussion about architecture qualification, the release team concluded that it would be interesting to have a better way to track architecture-specific bugs. It would be nice to have BTS tags for each architecture that is currently in the archive. It might also make sense to have tags for the architectures on debian-ports, to be able to filter issues about these easily. This sounds reasonable; are only tags required, or do we need more infrastructure than that? These are the list of ports that I see: amd64 armel armhf hurd-i386 i386 ia64 kfreebsd-amd64 kfreebsd-i386 mips mipsel powerpc s390x sparc avr32 sh What else am I missing? [I note that http://www.debian.org/ports/#portlist-released seems to have a reasonable list of ports, and http://anonscm.debian.org/viewvc/webwml/webwml/english/releases/sid/archive.data?view=markup has another; I'd like to reference a canonical location for ports (perhaps maintained by debian-ports or similar) so I don't have to figure out for myself which ports need a tag and what that tag should be, and which ports are just duplicates of other ports, and therefore don't need a tag. -- Don Armstrong http://www.donarmstrong.com There are two major products that come out of Berkeley: LSD and UNIX. We don't believe this to be a coincidence. -- Jeremy S. Anderson -- To UNSUBSCRIBE, email to debian-amd64-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20131123215315.gb7...@teltox.donarmstrong.com
Re: Bug#730258: please add arch-specific BTS tags
On 23 November 2013 21:53, Don Armstrong d...@debian.org wrote: On Sat, 23 Nov 2013, Ivo De Decker wrote: During a discussion about architecture qualification, the release team concluded that it would be interesting to have a better way to track architecture-specific bugs. It would be nice to have BTS tags for each architecture that is currently in the archive. It might also make sense to have tags for the architectures on debian-ports, to be able to filter issues about these easily. This sounds reasonable; are only tags required, or do we need more infrastructure than that? These are the list of ports that I see: amd64 armel armhf hurd-i386 i386 ia64 kfreebsd-amd64 kfreebsd-i386 mips mipsel powerpc s390x sparc avr32 sh What else am I missing? [I note that http://www.debian.org/ports/#portlist-released seems to have a reasonable list of ports, and http://anonscm.debian.org/viewvc/webwml/webwml/english/releases/sid/archive.data?view=markup has another; I'd like to reference a canonical location for ports (perhaps maintained by debian-ports or similar) so I don't have to figure out for myself which ports need a tag and what that tag should be, and which ports are just duplicates of other ports, and therefore don't need a tag. There are 484 reports usertagged debian-...@lists.debian.org arm64. Please consider including arm64 tag. Regards, Dmitrijs. -- To UNSUBSCRIBE, email to debian-amd64-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CANBHLUg0yh60VEh50NCbYK+nfs65F5x3jU6MFL+WEdqT=qz...@mail.gmail.com
Re: Bug#730258: please add arch-specific BTS tags
Don Armstrong dixit: These are the list of ports that I see: Question is, where do you see them? avr32 This one got removed even from debian-ports for several reasons. sh I think there's sh4 but not just sh. Looking at the buildd pages is probably the best idea. Combining https://buildd.debian.org/status/package.php?p=mksh and http://buildd.debian-ports.org/status/package.php?p=mksh (and ignoring s390 removal) gives us this list: alpha amd64 arm64 armel armhf hppa hurd-i386 i386 ia64 kfreebsd-amd64 kfreebsd-i386 m68k mips mipsel powerpc powerpcspe ppc64 s390x sh4 sparc sparc64 x32 This keeps hppa, which I’ve seen have some activity recently. has another; I'd like to reference a canonical location for ports (perhaps maintained by debian-ports or similar) so I don't have to Even the list on debian-ports is out of date wrt. debian-ports architectures – it misses x32 and arm64, for example. Sorry about that. There seems to be nobody keeping this list up to date so looking at the buildds seems best. Another option is of course to look at what dpkg supports, unearthing things like armeb, arm, avr32, sh3, etc. bye, //mirabilos -- „Also irgendwie hast du IMMER recht. Hier zuckelte gerade ein Triebwagen mit der Aufschrift Ostdeutsche Eisenbahn durch Wuppertal. Ich glaubs machmal nicht…“ -- Natureshadow, per SMS „Hilf mir mal grad beim Denken“ -- Natureshadow, IRL, 2x -- To UNSUBSCRIBE, email to debian-amd64-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/pine.bsm.4.64l.1311232243030.12...@herc.mirbsd.org
Re: Bug#730258: please add arch-specific BTS tags
On 11/23/2013 10:53 PM, Don Armstrong wrote: On Sat, 23 Nov 2013, Ivo De Decker wrote: During a discussion about architecture qualification, the release team concluded that it would be interesting to have a better way to track architecture-specific bugs. It would be nice to have BTS tags for each architecture that is currently in the archive. It might also make sense to have tags for the architectures on debian-ports, to be able to filter issues about these easily. This sounds reasonable; are only tags required, or do we need more infrastructure than that? These are the list of ports that I see: amd64 armel armhf hurd-i386 i386 ia64 kfreebsd-amd64 kfreebsd-i386 mips mipsel powerpc s390x sparc avr32 sh What else am I missing? Please add hppa Helge -- To UNSUBSCRIBE, email to debian-amd64-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/5291317e.3020...@gmx.de
Re: Bug#730258: please add arch-specific BTS tags
On 11/23/2013 11:51 PM, Helge Deller wrote: What else am I missing? Please add hppa Assuming that you are one of the hppa guys, how is the port doing? Any chance that the buildds will be up and running again anytime soon? Cheers, Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 -- To UNSUBSCRIBE, email to debian-amd64-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/52913875.3080...@physik.fu-berlin.de
Re: Bug#730258: please add arch-specific BTS tags
On 11/24/2013 12:21 AM, John Paul Adrian Glaubitz wrote: On 11/23/2013 11:51 PM, Helge Deller wrote: Please add hppa Assuming that you are one of the hppa guys, how is the port doing? Any chance that the buildds will be up and running again anytime soon? Yes, think so. I'm working on that just right now... Helge -- To UNSUBSCRIBE, email to debian-amd64-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/529138b5.5050...@gmx.de
Re: Bug#730258: please add arch-specific BTS tags
On 11/24/2013 12:22 AM, Helge Deller wrote: On 11/24/2013 12:21 AM, John Paul Adrian Glaubitz wrote: On 11/23/2013 11:51 PM, Helge Deller wrote: Please add hppa Assuming that you are one of the hppa guys, how is the port doing? Any chance that the buildds will be up and running again anytime soon? Yes, think so. I'm working on that just right now... Very cool! Hope you guys will soon be where we already are with the m68k port :). Crossing my fingers! It's been sad to see the number of up-to-date packages in hppa dropping over the time. Keep us updated! Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 -- To UNSUBSCRIBE, email to debian-amd64-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/52913bad.9000...@physik.fu-berlin.de
Re: Bug#730258: please add arch-specific BTS tags
On 11/24/2013 12:47 AM, John David Anglin wrote: On 23-Nov-13, at 6:35 PM, John Paul Adrian Glaubitz wrote: Crossing my fingers! It's been sad to see the number of up-to-date packages in hppa dropping over the time. It should be going up now. So, the buildds are already up and running? Shouldn't they be showing up on buildd.debian-ports.org [1]? Adrian [1] http://buildd.debian-ports.org/status/architecture.php?a=hppasuite=sid -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 -- To UNSUBSCRIBE, email to debian-amd64-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/52913f09.6080...@physik.fu-berlin.de
Re: Bug#730258: please add arch-specific BTS tags
On 23-Nov-13, at 6:35 PM, John Paul Adrian Glaubitz wrote: Crossing my fingers! It's been sad to see the number of up-to-date packages in hppa dropping over the time. It should be going up now. Dave -- John David Anglin dave.ang...@bell.net -- To UNSUBSCRIBE, email to debian-amd64-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/blu0-smtp50b10a8a25fb6dfae41df297...@phx.gbl
Re: Bug#730258: please add arch-specific BTS tags
On Sun, Nov 24, 2013 at 5:53 AM, Don Armstrong wrote: These are the list of ports that I see: I would strongly suggest not hardcoding this list and instead harvesting the Architecture fields of the Release files for oldstable - experimental on ftp.d.o, ftp.d-p.o and maybe archive.d.o. We have made this mistake and similar ones (usually hardcoding release codenames) in the QA infrastructure and it has bitten us hard in the past. Lets not make that mistake here. The release files are the closest to a canonical list of ports. There are other ports out there not maintained on d-p.o (like the Interix or Solaris ones for example) but I don't think we need to bother about those until they move closer to Debian. -- bye, pabs http://wiki.debian.org/PaulWise -- To UNSUBSCRIBE, email to debian-amd64-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/caktje6evh+_xumxvgd5w8a8kd1laxgggylnmuxstbllu4ou...@mail.gmail.com
Re: Bug#730258: please add arch-specific BTS tags
John Paul Adrian Glaubitz dixit: On 11/24/2013 12:47 AM, John David Anglin wrote: It should be going up now. So, the buildds are already up and running? Shouldn't they be showing up on buildd.debian-ports.org [1]? I think I saw buildd uploads for hppa on incoming.d.o this week. Paul Wise dixit: are other ports out there not maintained on d-p.o (like the Interix or Huh, the Interix port is not vaporware? Interesting… bye, //mirabilos -- hecker cool ein Ada Lovelace Google-Doodle. aber zum 197. Geburtstag? Hätten die nicht noch 3 Jahre warten können? mirabilos bis dahin gibts google nicht mehr hecker ja, könnte man meinen. wahrscheinlich ist der angekündigte welt- untergang aus dem maya-kalender die globale abschaltung von google ☺ und darum müssen die die doodles vorher noch raushauen -- To UNSUBSCRIBE, email to debian-amd64-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/pine.bsm.4.64l.1311240019570.12...@herc.mirbsd.org
Re: Bug#730258: please add arch-specific BTS tags
On 11/24/2013 01:20 AM, Thorsten Glaser wrote: John Paul Adrian Glaubitz dixit: So, the buildds are already up and running? Shouldn't they be showing up on buildd.debian-ports.org [1]? I think I saw buildd uploads for hppa on incoming.d.o this week. Indeed: http://incoming.debian-ports.org/buildd/packages/unstable/main/ Very cool! Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 -- To UNSUBSCRIBE, email to debian-amd64-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/529148de.8070...@physik.fu-berlin.de
Re: Bug#730258: please add arch-specific BTS tags
On Sun, 24 Nov 2013, Paul Wise wrote: On Sun, Nov 24, 2013 at 5:53 AM, Don Armstrong wrote: These are the list of ports that I see: I would strongly suggest not hardcoding this list and instead harvesting the Architecture fields of the Release files for oldstable - experimental on ftp.d.o, ftp.d-p.o and maybe archive.d.o. We have made this mistake and similar ones (usually hardcoding release codenames) in the QA infrastructure and it has bitten us hard in the past. Lets not make that mistake here. The list will be hardcoded, because it has to live in the Debbugs configuration file, and tags shouldn't disappear just because debian-ports or debian has dropped an architecture. That said, I was planning on setting it up so that I at least was notified when the set from cannonical location changed. The release files are the closest to a canonical list of ports. There are other ports out there not maintained on d-p.o (like the Interix or Solaris ones for example) but I don't think we need to bother about those until they move closer to Debian. OK. -- Don Armstrong http://www.donarmstrong.com There are two major products that come out of Berkeley: LSD and UNIX. We don't believe this to be a coincidence. -- Jeremy S. Anderson -- To UNSUBSCRIBE, email to debian-amd64-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20131124004708.gc7...@teltox.donarmstrong.com
Re: Bug#730258: please add arch-specific BTS tags
On 11/23/13 4:35 PM, John Paul Adrian Glaubitz wrote: On 11/24/2013 12:22 AM, Helge Deller wrote: On 11/24/2013 12:21 AM, John Paul Adrian Glaubitz wrote: On 11/23/2013 11:51 PM, Helge Deller wrote: Please add hppa Assuming that you are one of the hppa guys, how is the port doing? Any chance that the buildds will be up and running again anytime soon? Yes, think so. I'm working on that just right now... Very cool! Hope you guys will soon be where we already are with the m68k port :). Crossing my fingers! It's been sad to see the number of up-to-date packages in hppa dropping over the time. Keep us updated! Adrian [Sorry, meant to cc. this to the list] I'm currently working with Helge Deller and John David Anglin on kernel testing with one of my machines (64 Bit SMP - HP Visualize J6750 workstation). I'm not one of the official developers, but willing to donate time and machine resources to keep the port going. We've had some pretty interesting breakthroughs recently, regarding the 64 bit SMP kernel. Dave L. -- -- Dave Land Land Computer Service xmecha...@landcomp.net -- To UNSUBSCRIBE, email to debian-amd64-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/52915037.3020...@landcomp.net
Re: Bug#730258: please add arch-specific BTS tags
On 23/11/2013 22:53, Don Armstrong wrote: kfreebsd-amd64 kfreebsd-i386 Most of the bugs affecting one of these also affect the other. I think it makes sense to add a single tag to cover both. -- Robert Millan -- To UNSUBSCRIBE, email to debian-amd64-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/52915a2a.8010...@debian.org
Re: Fwd: Fwd: upgrade to jessie from wheezy with cuda problems
I set PCIe 3.0 permanently. With a system of 150K atoms there is no acceleration at all of molecular dynamics with ivy with respect to sandy bridge. At the end of this exercise, given the very meager acceleration with 500K atoms (which is a large system under any respect, even for supercomputers), one might wonder whether changing from sandy bridge to ivy bridge is worth the money. Of course, this the viewpoint of number crunching. One could test if PCIe 3.0 is more advantageous with CUDA-accelerated viewers like VMD (same house as the code NAMD for molecular dynamics). cheers francesco pietra On Nov 18, 2013 8:59 PM, Lennart Sorensen lsore...@csclub.uwaterloo.ca wrote: On Mon, Nov 18, 2013 at 10:39:53PM +0100, Francesco Pietra wrote: I forgot to mention that LnkSta 8GT/s is obtained only when actually carrying out the MD simulation. I believe to save power the link speed changes on the fly based on demand. -- Len Sorensen
Fwd: upgrade to jessie from wheezy with cuda problems
It is getting hard, unless I mistaken what was suggested by nvidia . Thus, following what was suggested by nvidia as a no-barrier solution, https://devtalk.nvidia.com/default/topic/545186/enabling-pcie-3-0-with-nvreg_enablepciegen3-on-titan/?offset=10#4021328 I updated the kernel boot string by 1) typing 'e' at grub prompt, 2) adding the option to the linux line, 3) Ctrl-x to boot If that procedure is correct (probably it is, as francesco@gig64:~$ cat /proc/cmdline BOOT_IMAGE=/boot/vmlinuz-3.10-3-amd64 root=/dev/mapper/vg1-root ro 1. nvidia.NVreg_EnablePCIeGen3=1 quiet francesco@gig64:~$ ) then, no luck. Both LnkCap and LnkSta were at at 5GT/s, as for PCIe 2.0. Molecular dynamics, accordingly, was not accelerated. I wonder whether 1. preceding nvidia... is what is needed for a grub bootloader option. I did not find any other instance about that nvidia suggestion on internet. francesco pietra -- Forwarded message -- From: Francesco Pietra chiendar...@gmail.com Date: Sun, Nov 17, 2013 at 4:09 PM Subject: Fwd: upgrade to jessie from wheezy with cuda problems To: amd64 Debian debian-amd64@lists.debian.org, Lennart Sorensen lsore...@csclub.uwaterloo.ca This addendum to let you know that simply adding 1. options nvidia NVreg_EnablePCIeGen3=1 to /etc/modprobe.d/nvidia.conf as suggested in https://devtalk.nvidia.com/default/topic/545186/enabling-pcie-3-0-with-nvreg_enablepciegen3-on-titan/ had no effect. Also, please note that what should be added to the kernel boot string, according to the same source, is nvidia.NVreg_EnablePCIeGen3=1 unlike I wrote before (i.e., no options, while a dot between nvidia and NVreg francesco pietra -- Forwarded message -- From: Francesco Pietra chiendar...@gmail.com Date: Sun, Nov 17, 2013 at 11:42 AM Subject: Fwd: upgrade to jessie from wheezy with cuda problems To: amd64 Debian debian-amd64@lists.debian.org, Lennart Sorensen lsore...@csclub.uwaterloo.ca Very sorry, forget about previous post. There, I had started MD from the gnome terminal, without activating the GPUUs. When carrying out regularly MD from the Linux prompt, without X-server, while activating the cards with #nvidia-smi -L #nvidia-smi -pm 1 as in all previous tests, both LnkCap and LnkSta are 5GT/s, as from PCIe 2.0. Thus, the problem seems to be activating PCIe 3.0, as before said. francesco pietra -- Forwarded message -- From: Francesco Pietra chiendar...@gmail.com Date: Sun, Nov 17, 2013 at 11:29 AM Subject: Fwd: upgrade to jessie from wheezy with cuda problems To: amd64 Debian debian-amd64@lists.debian.org, Lennart Sorensen lsore...@csclub.uwaterloo.ca I have to correct my previous report. When running molecular dynamics, the capability of the GPU is 5GT/, but the actual speed link is at 2.5GT/s, i.e., below PCIe 2.o #lspci - 02:00.0 VGA compatible controller: NVIDIA Corporation GK104 [GeForce GTX 680] (rev a1) (prog-if 00 [VGA controller]) Subsystem: NVIDIA Corporation Device 0969 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast TAbort- TAbort- MAbort- SERR- PERR- INTx- Latency: 0 Interrupt: pin A routed to IRQ 16 Region 0: Memory at fa00 (32-bit, non-prefetchable) [size=16M] Region 1: Memory at c000 (64-bit, prefetchable) [size=128M] Region 3: Memory at c800 (64-bit, prefetchable) [size=32M] Region 5: I/O ports at e000 [size=128] [virtual] Expansion ROM at fb00 [disabled] [size=512K] Capabilities: [60] Power Management version 3 Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) Status: D0 NoSoftRst+ PME-Enable- DSel=0 DScale=0 PME- Capabilities: [68] MSI: Enable- Count=1/1 Maskable- 64bit+ Address: Data: Capabilities: [78] Express (v2) Endpoint, MSI 00 DevCap:MaxPayload 256 bytes, PhantFunc 0, Latency L0s unlimited, L1 64us ExtTag+ AttnBtn- AttnInd- PwrInd- RBE+ FLReset- DevCtl:Report errors: Correctable- Non-Fatal- Fatal- Unsupported- RlxdOrd+ ExtTag+ PhantFunc- AuxPwr- NoSnoop+ MaxPayload 256 bytes, MaxReadReq 512 bytes DevSta:CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr- TransPend- LnkCap:Port #0, Speed 5GT/s, Width x16, ASPM L0s L1, Latency L0 512ns, L1 4us ClockPM+ Surprise- LLActRep- BwNot- LnkCtl:ASPM Disabled; RCB 64 bytes Disabled- Retrain- CommClk+ ExtSynch- ClockPM+ AutWidDis- BWInt- AutBWInt- LnkSta:Speed 2.5GT/s, Width x16, TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt- DevCap2: Completion Timeout: Range AB, TimeoutDis+, LTR-, OBFF Not Supported DevCtl2: Completion Timeout: 50us to 50ms, TimeoutDis-, LTR-, OBFF Disabled LnkCtl2: Target Link Speed: 5GT/s, EnterCompliance- SpeedDis- Transmit
Re: Fwd: upgrade to jessie from wheezy with cuda problems
Em 18-11-2013 13:13, Francesco Pietra escreveu: It is getting hard, unless I mistaken what was suggested by nvidia . Thus, following what was suggested by nvidia as a no-barrier solution, https://devtalk.nvidia.com/default/topic/545186/enabling-pcie-3-0-with-nvreg_enablepciegen3-on-titan/?offset=10#4021328 I updated the kernel boot string by 1) typing 'e' at grub prompt, 2) adding the option to the linux line, 3) Ctrl-x to boot If that procedure is correct (probably it is, as francesco@gig64:~$ cat /proc/cmdline BOOT_IMAGE=/boot/vmlinuz-3.10-3-amd64 root=/dev/mapper/vg1-root ro 1. nvidia.NVreg_EnablePCIeGen3=1 quiet francesco@gig64:~$ ) then, no luck. Both LnkCap and LnkSta were at at 5GT/s, as for PCIe 2.0. Molecular dynamics, accordingly, was not accelerated. I wonder whether 1. preceding nvidia... is what is needed for a grub bootloader option. I did not find any other instance about that nvidia suggestion on internet. I may be wrong, but it seems that there is a hardware bump in your pci-express 3.0 road , Francesco : http://www.anandtech.com/show/7521/nvidia-launches-tesla-k40 Close to the end it says that nvidia ... is finally enabling full pci-express 3.0 speeds ... , so it may be that your card suffers from this issue too . Hope it helps. -- To UNSUBSCRIBE, email to debian-amd64-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/528a3d42.1070...@gmail.com
Re: Fwd: upgrade to jessie from wheezy with cuda problems
Em 18-11-2013 13:13, Francesco Pietra escreveu: It is getting hard, unless I mistaken what was suggested by nvidia . Thus, following what was suggested by nvidia as a no-barrier solution, https://devtalk.nvidia.com/default/topic/545186/enabling-pcie-3-0-with-nvreg_enablepciegen3-on-titan/?offset=10#4021328 I updated the kernel boot string by 1) typing 'e' at grub prompt, 2) adding the option to the linux line, 3) Ctrl-x to boot If that procedure is correct (probably it is, as francesco@gig64:~$ cat /proc/cmdline BOOT_IMAGE=/boot/vmlinuz-3.10-3-amd64 root=/dev/mapper/vg1-root ro 1. nvidia.NVreg_EnablePCIeGen3=1 quiet francesco@gig64:~$ ) then, no luck. Both LnkCap and LnkSta were at at 5GT/s, as for PCIe 2.0. Molecular dynamics, accordingly, was not accelerated. I wonder whether 1. preceding nvidia... is what is needed for a grub bootloader option. I did not find any other instance about that nvidia suggestion on internet. I may be wrong, but it seems that there is a hardware bump in your pci-express 3.0 road , Francesco : http://www.anandtech.com/show/7521/nvidia-launches-tesla-k40 Close to the end it says that nvidia ... is finally enabling full pci-express 3.0 speeds ... , so it may be that your card suffers from this issue too . Hope it helps. -- To UNSUBSCRIBE, email to debian-amd64-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/528a3dcd.1090...@gmail.com
Re: Fwd: upgrade to jessie from wheezy with cuda problems
On Sun, Nov 17, 2013 at 10:45:58AM +0100, Francesco Pietra wrote: I am attacking the problem from another side, directly from within the OS itself: #lspi - tells that the link speed (= link status) LnkSta is at 5Gb/s, no matter whether the system is at number crunching or not. I.e., my system is at PCIe 2.0. This might explain why upgrading from sandy bridge to ivy bridge gave no speed gain of molecular dynamics. PCIe 3.0 was not achieved. As far as I could investigate, nvidia suggests to either: (1) Modify /etc/modprobe.d/local.conf (which does not exist on jessie) or create a new /etc/modprobe.d/nvidia.conf, adding to that 1. options nvidia NVreg_EnablePCIeGen3=1 Might need nvidia-current instead of nvidia. Actually, on my jessie, nvidia.conf reads alias nvidia nvidia-current remove nvidia-current rm mod nvidia Some guys found that useless, even when both grub-efi and initramfs are edited accordingly, so that nvidia offered a different move, updating the kernel boot string, by appending this: 1. options nvidia NVreg_EnablePCIeGen3=1 *** That is NOT the syntax for a kernel command line. It is the syntax for the modprobe config. Something like nvidia.NVreg_EnablePCIeGen3=1 or nvidia-current.NVreg_EnablePCIeGen3=1 (depending on the name of the module as far as the module is concerned). I did nothing, as I hope that the best adaptation to jessie may be suggested by those who know the OS better than me. The kind of information about links includes: LnkSta: the actual speed LnkCap: the capacity of the specific port, as far as I can understand. LnkCtl: ?? One could also run #lspci -vt to determine the bus where the GPU card is located, then running # lspci -vv -s ## where ## is the location. ** So, it is a tricky matter, but perhaps not so much when one knows where to put the hands. At any event, being unable to go to 8GT/s, as from PCIe 3.0, means loosing time and energy (=money and pollution), at least when the GPUs are used for long number crunching. Well it means slower transfers of data to and from the card. If the data set fits in the card entirely during a long number crunch, then bandwidth would not matter much at all. So depends on the size of the data set and how often data has to be moved in and out of the card. I'll continue investigating. The above seems to be promising. Hope to get help. -- Len Sorensen -- To UNSUBSCRIBE, email to debian-amd64-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20131118170238.gm20...@csclub.uwaterloo.ca
Re: Fwd: upgrade to jessie from wheezy with cuda problems
Might need nvidia-current instead of nvidia. It failed to bring to PCIe 3.0 when inserted into nvidia.conf francesco@gig64:/etc/modprobe.d$ cat nvidia.conf alias nvidia nvidia-current remove nvidia-current rmmod nvidia # 1. options nvidia-current NVreg_EnablePCIeGen3=1 (of course it was not commented when the test was carried out) However, it brought to PCIe 3.0 when in the kernel GREAT SUGGESTION Thus, I added (temporarily) to GRUB by 1) typing 'e' at grub prompt, 2) adding the option to the END OF the linux line, 3) Ctrl-x to boot verifying that it was taken into accout ~$ cat /proc/cmdline BOOT_IMAGE=/boot/vmlinuz-3.10-3-amd64 root=/dev/mapper/vg1-root ro quiet 1. nvidia-current.NVreg_EnablePCIeGen3=1 #lspci - ... 02:00.0 VGA compatible controller: NVIDIA Corporation GK104 [GeForce GTX 680] (rev a1) (prog-if 00 [VGA controller]) Subsystem: NVIDIA Corporation Device 0969 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast TAbort- TAbort- MAbort- SERR- PERR- INTx- Latency: 0 Interrupt: pin A routed to IRQ 16 Region 0: Memory at fa00 (32-bit, non-prefetchable) [size=16M] Region 1: Memory at c000 (64-bit, prefetchable) [size=128M] Region 3: Memory at c800 (64-bit, prefetchable) [size=32M] Region 5: I/O ports at e000 [size=128] [virtual] Expansion ROM at fb00 [disabled] [size=512K] Capabilities: [60] Power Management version 3 Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) Status: D0 NoSoftRst+ PME-Enable- DSel=0 DScale=0 PME- Capabilities: [68] MSI: Enable- Count=1/1 Maskable- 64bit+ Address: Data: Capabilities: [78] Express (v2) Endpoint, MSI 00 DevCap:MaxPayload 256 bytes, PhantFunc 0, Latency L0s unlimited, L1 64us ExtTag+ AttnBtn- AttnInd- PwrInd- RBE+ FLReset- DevCtl:Report errors: Correctable- Non-Fatal- Fatal- Unsupported- RlxdOrd+ ExtTag+ PhantFunc- AuxPwr- NoSnoop+ MaxPayload 256 bytes, MaxReadReq 512 bytes DevSta:CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr- TransPend- LnkCap:Port #0, Speed 8GT/s, Width x16, ASPM L0s L1, Latency L0 1us, L1 4us ClockPM+ Surprise- LLActRep- BwNot- LnkCtl:ASPM Disabled; RCB 64 bytes Disabled- Retrain- CommClk+ ExtSynch- ClockPM+ AutWidDis- BWInt- AutBWInt- LnkSta:Speed 8GT/s, Width x16, TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt- DevCap2: Completion Timeout: Range AB, TimeoutDis+, LTR-, OBFF Not Supported DevCtl2: Completion Timeout: 50us to 50ms, TimeoutDis-, LTR-, OBFF Disabled LnkCtl2: Target Link Speed: 8GT/s, EnterCompliance- SpeedDis- Transmit Margin: Normal Operating Range, EnterModifiedCompliance- ComplianceSOS- Compliance De-emphasis: -6dB LnkSta2: Current De-emphasis Level: -6dB, EqualizationComplete+, EqualizationPhase1+ EqualizationPhase2+, EqualizationPhase3+, LinkEqualizationRequest+ Capabilities: [b4] Vendor Specific Information: Len=14 ? Capabilities: [100 v1] Virtual Channel Caps:LPEVC=0 RefClk=100ns PATEntryBits=1 Arb:Fixed- WRR32- WRR64- WRR128- Ctrl:ArbSelect=Fixed Status:InProgress- VC0:Caps:PATOffset=00 MaxTimeSlots=1 RejSnoopTrans- Arb:Fixed- WRR32- WRR64- WRR128- TWRR128- WRR256- Ctrl:Enable+ ID=0 ArbSelect=Fixed TC/VC=01 Status:NegoPending- InProgress- Capabilities: [128 v1] Power Budgeting ? Capabilities: [600 v1] Vendor Specific Information: ID=0001 Rev=1 Len=024 ? Capabilities: [900 v1] #19 Kernel driver in use: nvidia ... The same for the other GPU. * Well, the surprise was that molecular dynamics for a large system (500K atoms) was very modestly accelerated. From the simulation log file: Info: Benchmark time: 6 CPUs 0.123387 s/step 1.4281 days/ns 1171.53 MB memory From the same simulation with same motherboard and GTX-680, but with sansy bridge i7-3930 and 1066MHz RAM: Info: Benchmark time: 6 CPUs 0.138832 s/step 1.60686 days/ns 1161.23 MB memory The better performance of the ivy bridge might be the result from the higher clock of both the CPU and RAM (1866MHz). A variety of interpretaions of these observations are possible, taking into account, however, that with simple machines as the one used here, it would be difficult to run MD with much bigger systems than 500K atoms. Finally we succeeded to get PCIe 3.0 and now the PCIe 3.0 setting can be passed permanently to the kernel. I have to learn how. Thanks a lot francesco pietra On Mon, Nov 18, 2013 at 6:02 PM, Lennart Sorensen lsore...@csclub.uwaterloo.ca wrote: On Sun, Nov 17, 2013 at
Fwd: Fwd: upgrade to jessie from wheezy with cuda problems
I forgot to mention that LnkSta 8GT/s is obtained only when actually carrying out the MD simulation. fp -- Forwarded message -- From: Francesco Pietra chiendar...@gmail.com Date: Mon, Nov 18, 2013 at 10:37 PM Subject: Re: Fwd: upgrade to jessie from wheezy with cuda problems To: Lennart Sorensen lsore...@csclub.uwaterloo.ca Cc: amd64 Debian debian-amd64@lists.debian.org Might need nvidia-current instead of nvidia. It failed to bring to PCIe 3.0 when inserted into nvidia.conf francesco@gig64:/etc/modprobe.d$ cat nvidia.conf alias nvidia nvidia-current remove nvidia-current rmmod nvidia # 1. options nvidia-current NVreg_EnablePCIeGen3=1 (of course it was not commented when the test was carried out) However, it brought to PCIe 3.0 when in the kernel GREAT SUGGESTION Thus, I added (temporarily) to GRUB by 1) typing 'e' at grub prompt, 2) adding the option to the END OF the linux line, 3) Ctrl-x to boot verifying that it was taken into accout ~$ cat /proc/cmdline BOOT_IMAGE=/boot/vmlinuz-3.10-3-amd64 root=/dev/mapper/vg1-root ro quiet 1. nvidia-current.NVreg_EnablePCIeGen3=1 #lspci - ... 02:00.0 VGA compatible controller: NVIDIA Corporation GK104 [GeForce GTX 680] (rev a1) (prog-if 00 [VGA controller]) Subsystem: NVIDIA Corporation Device 0969 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast TAbort- TAbort- MAbort- SERR- PERR- INTx- Latency: 0 Interrupt: pin A routed to IRQ 16 Region 0: Memory at fa00 (32-bit, non-prefetchable) [size=16M] Region 1: Memory at c000 (64-bit, prefetchable) [size=128M] Region 3: Memory at c800 (64-bit, prefetchable) [size=32M] Region 5: I/O ports at e000 [size=128] [virtual] Expansion ROM at fb00 [disabled] [size=512K] Capabilities: [60] Power Management version 3 Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) Status: D0 NoSoftRst+ PME-Enable- DSel=0 DScale=0 PME- Capabilities: [68] MSI: Enable- Count=1/1 Maskable- 64bit+ Address: Data: Capabilities: [78] Express (v2) Endpoint, MSI 00 DevCap:MaxPayload 256 bytes, PhantFunc 0, Latency L0s unlimited, L1 64us ExtTag+ AttnBtn- AttnInd- PwrInd- RBE+ FLReset- DevCtl:Report errors: Correctable- Non-Fatal- Fatal- Unsupported- RlxdOrd+ ExtTag+ PhantFunc- AuxPwr- NoSnoop+ MaxPayload 256 bytes, MaxReadReq 512 bytes DevSta:CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr- TransPend- LnkCap:Port #0, Speed 8GT/s, Width x16, ASPM L0s L1, Latency L0 1us, L1 4us ClockPM+ Surprise- LLActRep- BwNot- LnkCtl:ASPM Disabled; RCB 64 bytes Disabled- Retrain- CommClk+ ExtSynch- ClockPM+ AutWidDis- BWInt- AutBWInt- LnkSta:Speed 8GT/s, Width x16, TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt- DevCap2: Completion Timeout: Range AB, TimeoutDis+, LTR-, OBFF Not Supported DevCtl2: Completion Timeout: 50us to 50ms, TimeoutDis-, LTR-, OBFF Disabled LnkCtl2: Target Link Speed: 8GT/s, EnterCompliance- SpeedDis- Transmit Margin: Normal Operating Range, EnterModifiedCompliance- ComplianceSOS- Compliance De-emphasis: -6dB LnkSta2: Current De-emphasis Level: -6dB, EqualizationComplete+, EqualizationPhase1+ EqualizationPhase2+, EqualizationPhase3+, LinkEqualizationRequest+ Capabilities: [b4] Vendor Specific Information: Len=14 ? Capabilities: [100 v1] Virtual Channel Caps:LPEVC=0 RefClk=100ns PATEntryBits=1 Arb:Fixed- WRR32- WRR64- WRR128- Ctrl:ArbSelect=Fixed Status:InProgress- VC0:Caps:PATOffset=00 MaxTimeSlots=1 RejSnoopTrans- Arb:Fixed- WRR32- WRR64- WRR128- TWRR128- WRR256- Ctrl:Enable+ ID=0 ArbSelect=Fixed TC/VC=01 Status:NegoPending- InProgress- Capabilities: [128 v1] Power Budgeting ? Capabilities: [600 v1] Vendor Specific Information: ID=0001 Rev=1 Len=024 ? Capabilities: [900 v1] #19 Kernel driver in use: nvidia ... The same for the other GPU. * Well, the surprise was that molecular dynamics for a large system (500K atoms) was very modestly accelerated. From the simulation log file: Info: Benchmark time: 6 CPUs 0.123387 s/step 1.4281 days/ns 1171.53 MB memory From the same simulation with same motherboard and GTX-680, but with sansy bridge i7-3930 and 1066MHz RAM: Info: Benchmark time: 6 CPUs 0.138832 s/step 1.60686 days/ns 1161.23 MB memory The better performance of the ivy bridge might be the result from the higher clock of both the CPU and RAM (1866MHz). A variety of interpretaions of these observations are possible, taking into account, however, that
Re: Fwd: Fwd: upgrade to jessie from wheezy with cuda problems
On Mon, Nov 18, 2013 at 10:39:53PM +0100, Francesco Pietra wrote: I forgot to mention that LnkSta 8GT/s is obtained only when actually carrying out the MD simulation. I believe to save power the link speed changes on the fly based on demand. -- Len Sorensen -- To UNSUBSCRIBE, email to debian-amd64-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20131118215951.go20...@csclub.uwaterloo.ca
Re: Fwd: upgrade to jessie from wheezy with cuda problems
I am attacking the problem from another side, directly from within the OS itself: #lspi - tells that the link speed (= link status) LnkSta is at 5Gb/s, no matter whether the system is at number crunching or not. I.e., my system is at PCIe 2.0. This might explain why upgrading from sandy bridge to ivy bridge gave no speed gain of molecular dynamics. PCIe 3.0 was not achieved. As far as I could investigate, nvidia suggests to either: (1) Modify /etc/modprobe.d/local.conf (which does not exist on jessie) or create a new /etc/modprobe.d/nvidia.conf, adding to that 1. options nvidia NVreg_EnablePCIeGen3=1 Actually, on my jessie, nvidia.conf reads alias nvidia nvidia-current remove nvidia-current rm mod nvidia Some guys found that useless, even when both grub-efi and initramfs are edited accordingly, so that nvidia offered a different move, updating the kernel boot string, by appending this: 1. options nvidia NVreg_EnablePCIeGen3=1 *** I did nothing, as I hope that the best adaptation to jessie may be suggested by those who know the OS better than me. The kind of information about links includes: LnkSta: the actual speed LnkCap: the capacity of the specific port, as far as I can understand. LnkCtl: ?? One could also run #lspci -vt to determine the bus where the GPU card is located, then running # lspci -vv -s ## where ## is the location. ** So, it is a tricky matter, but perhaps not so much when one knows where to put the hands. At any event, being unable to go to 8GT/s, as from PCIe 3.0, means loosing time and energy (=money and pollution), at least when the GPUs are used for long number crunching. I'll continue investigating. The above seems to be promising. Hope to get help. francesco pietra PS With my jessie /etc/modprobe.d includes the following files: alsa-base.conf alsa-case-blacklist.conf dkms.conf (which has no active statemente) fbdev-blacklist.conf i915-kms.conf nvidia.conf nvidia-blacklist-nouveau.conf radeon-kms.conf ** On Thu, Nov 14, 2013 at 3:33 AM, Lennart Sorensen lsore...@csclub.uwaterloo.ca wrote: On Wed, Nov 13, 2013 at 05:43:47PM -0500, Lennart Sorensen wrote: On Wed, Nov 13, 2013 at 10:53:30PM +0100, Francesco Pietra wrote: francesco@gig64:~/tmp$ file ./CUDA-Z-0.7.189.run ./CUDA-Z-0.7.189.run: data francesco@gig64:~/tmp$ OK that's weird. I expected to see x86 32 or 64bit binary. Seems to be a shell scripts with compressed code in it. Yuck. :) OK I got it running. It is a 32bit binary. I had to install these: ii libcuda1:i386 331.20-1 i386 NVIDIA CUDA runtime library ii libcudart5.0:i386 5.0.35-8 i386 NVIDIA CUDA runtime library ii libgl1-nvidia-glx:i386331.20-1 i386 NVIDIA binary OpenGL libraries ii libstdc++6:i386 4.8.2-4 i386 GNU Standard C++ Library v3 ii libxrender1:i386 1:0.9.8-1 i386 X Rendering Extension client library ii zlib1g:i386 1:1.2.8.dfsg-1 i386 compression library - runtime Then I was able to run it. No messing with LD_LIBRARY_PATH or anything. To install :i386 packages you first have to enable multiarch support with dpkg and run apt-get update. So something like: dpkg --add-architecture i386 apt-get update apt-get install libcuda1:i386 libcudart5.0:i386 libgl1-nvidia-glx:i386 libstdc++6:i386 libxrender1:i386 zlib1g:i386 Don't worry about the exact versions, since I am running unstable+experimental. You don;t need to do that to get it working. For your 64bit code you probably need libcuda1 libcudart5.0 and such installed in the 64bit version. -- Len Sorensen
Fwd: upgrade to jessie from wheezy with cuda problems
I have to correct my previous report. When running molecular dynamics, the capability of the GPU is 5GT/, but the actual speed link is at 2.5GT/s, i.e., below PCIe 2.o #lspci - 02:00.0 VGA compatible controller: NVIDIA Corporation GK104 [GeForce GTX 680] (rev a1) (prog-if 00 [VGA controller]) Subsystem: NVIDIA Corporation Device 0969 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast TAbort- TAbort- MAbort- SERR- PERR- INTx- Latency: 0 Interrupt: pin A routed to IRQ 16 Region 0: Memory at fa00 (32-bit, non-prefetchable) [size=16M] Region 1: Memory at c000 (64-bit, prefetchable) [size=128M] Region 3: Memory at c800 (64-bit, prefetchable) [size=32M] Region 5: I/O ports at e000 [size=128] [virtual] Expansion ROM at fb00 [disabled] [size=512K] Capabilities: [60] Power Management version 3 Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) Status: D0 NoSoftRst+ PME-Enable- DSel=0 DScale=0 PME- Capabilities: [68] MSI: Enable- Count=1/1 Maskable- 64bit+ Address: Data: Capabilities: [78] Express (v2) Endpoint, MSI 00 DevCap:MaxPayload 256 bytes, PhantFunc 0, Latency L0s unlimited, L1 64us ExtTag+ AttnBtn- AttnInd- PwrInd- RBE+ FLReset- DevCtl:Report errors: Correctable- Non-Fatal- Fatal- Unsupported- RlxdOrd+ ExtTag+ PhantFunc- AuxPwr- NoSnoop+ MaxPayload 256 bytes, MaxReadReq 512 bytes DevSta:CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr- TransPend- LnkCap:Port #0, Speed 5GT/s, Width x16, ASPM L0s L1, Latency L0 512ns, L1 4us ClockPM+ Surprise- LLActRep- BwNot- LnkCtl:ASPM Disabled; RCB 64 bytes Disabled- Retrain- CommClk+ ExtSynch- ClockPM+ AutWidDis- BWInt- AutBWInt- LnkSta:Speed 2.5GT/s, Width x16, TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt- DevCap2: Completion Timeout: Range AB, TimeoutDis+, LTR-, OBFF Not Supported DevCtl2: Completion Timeout: 50us to 50ms, TimeoutDis-, LTR-, OBFF Disabled LnkCtl2: Target Link Speed: 5GT/s, EnterCompliance- SpeedDis- Transmit Margin: Normal Operating Range, EnterModifiedCompliance- ComplianceSOS- Compliance De-emphasis: -6dB LnkSta2: Current De-emphasis Level: -6dB, EqualizationComplete+, EqualizationPhase1+ EqualizationPhase2+, EqualizationPhase3+, LinkEqualizationRequest- francesco pietra -- Forwarded message -- From: Francesco Pietra chiendar...@gmail.com Date: Tue, Nov 12, 2013 at 3:54 PM Subject: upgrade to jessie from wheezy with cuda problems To: amd64 Debian debian-amd64@lists.debian.org Hello: I decided to try jessie to get PCIe 3.0 with a recent nvidia driver, thus upgrading from wheezy. wheezy was uname -r 3.2.0-4-amd64 nvidia-smi 304.88 nvcc --version 4.2 (the latter is also the version at which the molecular dynamics code was compiled, and used without calling the X-server) Following aptitude update aptitude-upgrade a number of dependecies related to gnome were not met (evolution-common lbfolks25 gnome-panel gnome-shell gnome-theme-extras gnome-theme-standard libreoffice-evolution). This notwithstanding, I decided to upgrade. After rebooting to get linux matching with nvidia: nvcc --version 5.0 uname -r 3.10-3-amd64 nvidia-smi the nvidia kernel module has version 304.108 but the nvidia driver component has version 319.60. Driver 319.6 is just what I wanted. Now, how best fix the problems? Install linux image 3.2? In the past I tried dist-upgrade, getting into devastating problems. thanks francesco pietra PS I was advised that debian is getting bounces from my address above. If so, please try my institutional address francesco.pie...@accademialucchese.it
Fwd: upgrade to jessie from wheezy with cuda problems
Very sorry, forget about previous post. There, I had started MD from the gnome terminal, without activating the GPUUs. When carrying out regularly MD from the Linux prompt, without X-server, while activating the cards with #nvidia-smi -L #nvidia-smi -pm 1 as in all previous tests, both LnkCap and LnkSta are 5GT/s, as from PCIe 2.0. Thus, the problem seems to be activating PCIe 3.0, as before said. francesco pietra -- Forwarded message -- From: Francesco Pietra chiendar...@gmail.com Date: Sun, Nov 17, 2013 at 11:29 AM Subject: Fwd: upgrade to jessie from wheezy with cuda problems To: amd64 Debian debian-amd64@lists.debian.org, Lennart Sorensen lsore...@csclub.uwaterloo.ca I have to correct my previous report. When running molecular dynamics, the capability of the GPU is 5GT/, but the actual speed link is at 2.5GT/s, i.e., below PCIe 2.o #lspci - 02:00.0 VGA compatible controller: NVIDIA Corporation GK104 [GeForce GTX 680] (rev a1) (prog-if 00 [VGA controller]) Subsystem: NVIDIA Corporation Device 0969 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast TAbort- TAbort- MAbort- SERR- PERR- INTx- Latency: 0 Interrupt: pin A routed to IRQ 16 Region 0: Memory at fa00 (32-bit, non-prefetchable) [size=16M] Region 1: Memory at c000 (64-bit, prefetchable) [size=128M] Region 3: Memory at c800 (64-bit, prefetchable) [size=32M] Region 5: I/O ports at e000 [size=128] [virtual] Expansion ROM at fb00 [disabled] [size=512K] Capabilities: [60] Power Management version 3 Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) Status: D0 NoSoftRst+ PME-Enable- DSel=0 DScale=0 PME- Capabilities: [68] MSI: Enable- Count=1/1 Maskable- 64bit+ Address: Data: Capabilities: [78] Express (v2) Endpoint, MSI 00 DevCap:MaxPayload 256 bytes, PhantFunc 0, Latency L0s unlimited, L1 64us ExtTag+ AttnBtn- AttnInd- PwrInd- RBE+ FLReset- DevCtl:Report errors: Correctable- Non-Fatal- Fatal- Unsupported- RlxdOrd+ ExtTag+ PhantFunc- AuxPwr- NoSnoop+ MaxPayload 256 bytes, MaxReadReq 512 bytes DevSta:CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr- TransPend- LnkCap:Port #0, Speed 5GT/s, Width x16, ASPM L0s L1, Latency L0 512ns, L1 4us ClockPM+ Surprise- LLActRep- BwNot- LnkCtl:ASPM Disabled; RCB 64 bytes Disabled- Retrain- CommClk+ ExtSynch- ClockPM+ AutWidDis- BWInt- AutBWInt- LnkSta:Speed 2.5GT/s, Width x16, TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt- DevCap2: Completion Timeout: Range AB, TimeoutDis+, LTR-, OBFF Not Supported DevCtl2: Completion Timeout: 50us to 50ms, TimeoutDis-, LTR-, OBFF Disabled LnkCtl2: Target Link Speed: 5GT/s, EnterCompliance- SpeedDis- Transmit Margin: Normal Operating Range, EnterModifiedCompliance- ComplianceSOS- Compliance De-emphasis: -6dB LnkSta2: Current De-emphasis Level: -6dB, EqualizationComplete+, EqualizationPhase1+ EqualizationPhase2+, EqualizationPhase3+, LinkEqualizationRequest- francesco pietra -- Forwarded message -- From: Francesco Pietra chiendar...@gmail.com Date: Tue, Nov 12, 2013 at 3:54 PM Subject: upgrade to jessie from wheezy with cuda problems To: amd64 Debian debian-amd64@lists.debian.org Hello: I decided to try jessie to get PCIe 3.0 with a recent nvidia driver, thus upgrading from wheezy. wheezy was uname -r 3.2.0-4-amd64 nvidia-smi 304.88 nvcc --version 4.2 (the latter is also the version at which the molecular dynamics code was compiled, and used without calling the X-server) Following aptitude update aptitude-upgrade a number of dependecies related to gnome were not met (evolution-common lbfolks25 gnome-panel gnome-shell gnome-theme-extras gnome-theme-standard libreoffice-evolution). This notwithstanding, I decided to upgrade. After rebooting to get linux matching with nvidia: nvcc --version 5.0 uname -r 3.10-3-amd64 nvidia-smi the nvidia kernel module has version 304.108 but the nvidia driver component has version 319.60. Driver 319.6 is just what I wanted. Now, how best fix the problems? Install linux image 3.2? In the past I tried dist-upgrade, getting into devastating problems. thanks francesco pietra PS I was advised that debian is getting bounces from my address above. If so, please try my institutional address francesco.pie...@accademialucchese.it
Re: device entry missing after reboot...
Stefan, were you able to find solution? I'm facing same exact issue: /dev/sdd1 missing after reboot, it's also part of RAID I'm running CentOS 6.4 though Thank you Vlad
Fwd: upgrade to jessie from wheezy with cuda problems
This addendum to let you know that simply adding 1. options nvidia NVreg_EnablePCIeGen3=1 to /etc/modprobe.d/nvidia.conf as suggested in https://devtalk.nvidia.com/default/topic/545186/enabling-pcie-3-0-with-nvreg_enablepciegen3-on-titan/ had no effect. Also, please note that what should be added to the kernel boot string, according to the same source, is nvidia.NVreg_EnablePCIeGen3=1 unlike I wrote before (i.e., no options, while a dot between nvidia and NVreg francesco pietra -- Forwarded message -- From: Francesco Pietra chiendar...@gmail.com Date: Sun, Nov 17, 2013 at 11:42 AM Subject: Fwd: upgrade to jessie from wheezy with cuda problems To: amd64 Debian debian-amd64@lists.debian.org, Lennart Sorensen lsore...@csclub.uwaterloo.ca Very sorry, forget about previous post. There, I had started MD from the gnome terminal, without activating the GPUUs. When carrying out regularly MD from the Linux prompt, without X-server, while activating the cards with #nvidia-smi -L #nvidia-smi -pm 1 as in all previous tests, both LnkCap and LnkSta are 5GT/s, as from PCIe 2.0. Thus, the problem seems to be activating PCIe 3.0, as before said. francesco pietra -- Forwarded message -- From: Francesco Pietra chiendar...@gmail.com Date: Sun, Nov 17, 2013 at 11:29 AM Subject: Fwd: upgrade to jessie from wheezy with cuda problems To: amd64 Debian debian-amd64@lists.debian.org, Lennart Sorensen lsore...@csclub.uwaterloo.ca I have to correct my previous report. When running molecular dynamics, the capability of the GPU is 5GT/, but the actual speed link is at 2.5GT/s, i.e., below PCIe 2.o #lspci - 02:00.0 VGA compatible controller: NVIDIA Corporation GK104 [GeForce GTX 680] (rev a1) (prog-if 00 [VGA controller]) Subsystem: NVIDIA Corporation Device 0969 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast TAbort- TAbort- MAbort- SERR- PERR- INTx- Latency: 0 Interrupt: pin A routed to IRQ 16 Region 0: Memory at fa00 (32-bit, non-prefetchable) [size=16M] Region 1: Memory at c000 (64-bit, prefetchable) [size=128M] Region 3: Memory at c800 (64-bit, prefetchable) [size=32M] Region 5: I/O ports at e000 [size=128] [virtual] Expansion ROM at fb00 [disabled] [size=512K] Capabilities: [60] Power Management version 3 Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) Status: D0 NoSoftRst+ PME-Enable- DSel=0 DScale=0 PME- Capabilities: [68] MSI: Enable- Count=1/1 Maskable- 64bit+ Address: Data: Capabilities: [78] Express (v2) Endpoint, MSI 00 DevCap:MaxPayload 256 bytes, PhantFunc 0, Latency L0s unlimited, L1 64us ExtTag+ AttnBtn- AttnInd- PwrInd- RBE+ FLReset- DevCtl:Report errors: Correctable- Non-Fatal- Fatal- Unsupported- RlxdOrd+ ExtTag+ PhantFunc- AuxPwr- NoSnoop+ MaxPayload 256 bytes, MaxReadReq 512 bytes DevSta:CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr- TransPend- LnkCap:Port #0, Speed 5GT/s, Width x16, ASPM L0s L1, Latency L0 512ns, L1 4us ClockPM+ Surprise- LLActRep- BwNot- LnkCtl:ASPM Disabled; RCB 64 bytes Disabled- Retrain- CommClk+ ExtSynch- ClockPM+ AutWidDis- BWInt- AutBWInt- LnkSta:Speed 2.5GT/s, Width x16, TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt- DevCap2: Completion Timeout: Range AB, TimeoutDis+, LTR-, OBFF Not Supported DevCtl2: Completion Timeout: 50us to 50ms, TimeoutDis-, LTR-, OBFF Disabled LnkCtl2: Target Link Speed: 5GT/s, EnterCompliance- SpeedDis- Transmit Margin: Normal Operating Range, EnterModifiedCompliance- ComplianceSOS- Compliance De-emphasis: -6dB LnkSta2: Current De-emphasis Level: -6dB, EqualizationComplete+, EqualizationPhase1+ EqualizationPhase2+, EqualizationPhase3+, LinkEqualizationRequest- francesco pietra -- Forwarded message -- From: Francesco Pietra chiendar...@gmail.com Date: Tue, Nov 12, 2013 at 3:54 PM Subject: upgrade to jessie from wheezy with cuda problems To: amd64 Debian debian-amd64@lists.debian.org Hello: I decided to try jessie to get PCIe 3.0 with a recent nvidia driver, thus upgrading from wheezy. wheezy was uname -r 3.2.0-4-amd64 nvidia-smi 304.88 nvcc --version 4.2 (the latter is also the version at which the molecular dynamics code was compiled, and used without calling the X-server) Following aptitude update aptitude-upgrade a number of dependecies related to gnome were not met (evolution-common lbfolks25 gnome-panel gnome-shell gnome-theme-extras gnome-theme-standard libreoffice-evolution). This notwithstanding, I decided to upgrade. After rebooting to get linux matching with nvidia: nvcc --version 5.0 uname -r
Re: upgrade to jessie from wheezy with cuda problems
I think it was renamed. No idea why. modinfo nvidia-current should work though. Yes, it does. Do you have the cuda libraries for the 319 version installed? Yes I don't play around with GPU computations, but from what I have read it does need a certain size job before the overhead of transfering the data and managing the GPU makse it worthwhile, but for large jobs the high core count and memory bandwidth makes a big difference. 500,000 atoms, as in my test, is a large system for unbiased molecular dynamics. At any event, I looked at the the nvidia-cuda-toolkit version 5.0. nvidia for GPU Computing SDK, to build examples that should include a bandwidth test, offers linux packages for Fedora RHEL Ubuntu OpenSUSE and SUSE. No Debian. I had unpleasant experiences with Ubuntu packages, and it is well known that Ubuntu, unlike LinuxMint, is not compatible with Debian. Therefore, I did not try the cuda toolkit. I wonder why Ubuntu has so widely replaced Debian among the mass. Sad, and somewhat irritating, for me. I tried francesco@gig64:~/tmp$ ls CUDA-Z-0.7.189.run francesco@gig64:~/tmp$ ./CUDA-Z-0.7.189.run CUDA-Z 0.7.189 Container Starting CUDA-Z... /home/francesco/tmp/CUDA-Z-657a-580e-a8aa-0faa/cuda-z: error while loading shared libraries: libXrender.so.1: cannot open shared object file: No such file or directory francesco@gig64:~/tmp$ ls CUDA-Z-0.7.189.run libXrender.so.1 francesco@gig64:~/tmp$ ./CUDA-Z-0.7.189.run CUDA-Z 0.7.189 Container Starting CUDA-Z... /home/francesco/tmp/CUDA-Z-a3db-49bf-8cb7-059d/cuda-z: error while loading shared libraries: libXrender.so.1: cannot open shared object file: No such file or directory francesco@gig64:~/tmp$ Actually the required lib is available, as shown by my copy into tmp. I don't remember the source of this GNU CUDA-Z tool. Any experience with? I have also met reports of unexciting experience with PCIe 3.0, that is meager or no gain over PCIe 2.0, however it deals of people carrying out games, which is different from NAMD molecular dynamics, where most is done by the GPUs but AT EACH STEP energy has to be calculated by the CPU. thanks francesco pietra On Tue, Nov 12, 2013 at 11:37 PM, Lennart Sorensen lsore...@csclub.uwaterloo.ca wrote: On Tue, Nov 12, 2013 at 10:35:53PM +0100, Francesco Pietra wrote: # apt-get --purge remove *legacy* did the job. I wonder how these legacy packages entered the scene while updating/upgrading from a clean wheezy. The bad news are that with the new driver 319.60 there was no acceleration of molecular dynamics for a job of modest size (150K atoms) and slight acceleration (0.12 s/step vs 0.14 s/step) for a heavy job (500K atoms). Weather bringing from PCIe 2.0 (with the 304.xx driver of wheezy) to PCIe 3.0 (with driver 319.60 of jessie) (increasing the bandwidth from GPUs to RAM from 5 to 8GB/s) has not the effect that I hoped on the calculations, or PCIe is still 2.0 with jessie. Now, with cuda 5.0, it should be easy to measure the bandwidth directly. I have to learn how and I'll report about in due course. Now nvidia-smi activates the GPUs for normal work, nvidia-smi -L tells about the GPUs, dpkg -l |grep nvidia shows all 319.60 or 5.0.35-8, the X-server can be started and gnome loaded (startx, gnome-session), nvcc --version gives 5.0, however # modinfo nvidia ERROR: module nvidia not found In analogy with wheezy 3.2.0-4, I expected /lib/modules/3.10-3-amd64/updates/dkms/nvidia.ko Instead, there is /lib/modules/3.10-3-amd64/nvidia/nvidia-current.ko is that a feature of jessie or something wrong? I think it was renamed. No idea why. modinfo nvidia-current should work though. Do you have the cuda libraries for the 319 version installed? I don't play around with GPU computations, but from what I have read it does need a certain size job before the overhead of transfering the data and managing the GPU makse it worthwhile, but for large jobs the high core count and memory bandwidth makes a big difference. -- Len Sorensen
Re: upgrade to jessie from wheezy with cuda problems
My answer seems to have disappeared. I summarize here. modinfo nvidia-curred works well. CUDA libraries are installed. For nvidia-cuda-toolkit, nvidia offers SDK packages for Ubuntu, not for Debian. I don't like to get into troubles with Ubuntu, which, unlike LinuxMINT, is not compatible with Debian. I tried GNU CUDA-Z-07.189.run (don't remember from where it was downloaded). However it does not find the shared libXrender.so.1, even if made available into the same folder of CUDA-Z. Actually root@gig64:/home/francesco# apt-file search libXrender.so.1 libxrender1: /usr/lib/x86_64-linux-gnu/libXrender.so.1 libxrender1: /usr/lib/x86_64-linux-gnu/libXrender.so.1.3.0 libxrender1-dbg: /usr/lib/debug/usr/lib/x86_64-linux-gnu/libXrender.so.1.3.0 root@gig64:/home/francesco# francesco@gig64:~$ echo $PATH /opt/namd2.9_cuda4.0_2012-09-26/bin:/opt/namd2.9_cuda4.0_2012-09-26/bin:/opt/namd2.9_cuda4.0_2012-09-26/bin:/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games:/opt/amber12/bin:/opt/amber10/bin:/opt/UCSF/Chimera64-2012-10-10/bin:/opt/namd2.9_cuda4.0_2012-09-26/bin/namd2:/opt/amber12/bin:/opt/amber10/bin:/opt/UCSF/Chimera64-2012-10-10/bin:/opt/namd2.9_cuda4.0_2012-09-26/bin/namd2:/opt/amber12/bin:/opt/amber10/bin:/opt/UCSF/Chimera64-2012-10-10/bin:/opt/namd2.9_cuda4.0_2012-09-26/bin/namd2 francesco@gig64:~$ Should /usr/lib/x86_64-linux-gnu be put on my path explicitly? Thanks francesco pietra On Tue, Nov 12, 2013 at 11:37 PM, Lennart Sorensen lsore...@csclub.uwaterloo.ca wrote: On Tue, Nov 12, 2013 at 10:35:53PM +0100, Francesco Pietra wrote: # apt-get --purge remove *legacy* did the job. I wonder how these legacy packages entered the scene while updating/upgrading from a clean wheezy. The bad news are that with the new driver 319.60 there was no acceleration of molecular dynamics for a job of modest size (150K atoms) and slight acceleration (0.12 s/step vs 0.14 s/step) for a heavy job (500K atoms). Weather bringing from PCIe 2.0 (with the 304.xx driver of wheezy) to PCIe 3.0 (with driver 319.60 of jessie) (increasing the bandwidth from GPUs to RAM from 5 to 8GB/s) has not the effect that I hoped on the calculations, or PCIe is still 2.0 with jessie. Now, with cuda 5.0, it should be easy to measure the bandwidth directly. I have to learn how and I'll report about in due course. Now nvidia-smi activates the GPUs for normal work, nvidia-smi -L tells about the GPUs, dpkg -l |grep nvidia shows all 319.60 or 5.0.35-8, the X-server can be started and gnome loaded (startx, gnome-session), nvcc --version gives 5.0, however # modinfo nvidia ERROR: module nvidia not found In analogy with wheezy 3.2.0-4, I expected /lib/modules/3.10-3-amd64/updates/dkms/nvidia.ko Instead, there is /lib/modules/3.10-3-amd64/nvidia/nvidia-current.ko is that a feature of jessie or something wrong? I think it was renamed. No idea why. modinfo nvidia-current should work though. Do you have the cuda libraries for the 319 version installed? I don't play around with GPU computations, but from what I have read it does need a certain size job before the overhead of transfering the data and managing the GPU makse it worthwhile, but for large jobs the high core count and memory bandwidth makes a big difference. -- Len Sorensen
Re: upgrade to jessie from wheezy with cuda problems
On Wed, Nov 13, 2013 at 10:13:15AM +0100, Francesco Pietra wrote: I think it was renamed. No idea why. modinfo nvidia-current should work though. Yes, it does. Do you have the cuda libraries for the 319 version installed? Yes I don't play around with GPU computations, but from what I have read it does need a certain size job before the overhead of transfering the data and managing the GPU makse it worthwhile, but for large jobs the high core count and memory bandwidth makes a big difference. 500,000 atoms, as in my test, is a large system for unbiased molecular dynamics. At any event, I looked at the the nvidia-cuda-toolkit version 5.0. nvidia for GPU Computing SDK, to build examples that should include a bandwidth test, offers linux packages for Fedora RHEL Ubuntu OpenSUSE and SUSE. No Debian. I had unpleasant experiences with Ubuntu packages, and it is well known that Ubuntu, unlike LinuxMint, is not compatible with Debian. Therefore, I did not try the cuda toolkit. I wonder why Ubuntu has so widely replaced Debian among the mass. Sad, and somewhat irritating, for me. I tried francesco@gig64:~/tmp$ ls CUDA-Z-0.7.189.run francesco@gig64:~/tmp$ ./CUDA-Z-0.7.189.run CUDA-Z 0.7.189 Container Starting CUDA-Z... /home/francesco/tmp/CUDA-Z-657a-580e-a8aa-0faa/cuda-z: error while loading shared libraries: libXrender.so.1: cannot open shared object file: No such file or directory Try: LD_LIBRARY_PATH=. ./CUDA-Z-0.7.189.run See if it finds that lirary then. francesco@gig64:~/tmp$ ls CUDA-Z-0.7.189.run libXrender.so.1 francesco@gig64:~/tmp$ ./CUDA-Z-0.7.189.run CUDA-Z 0.7.189 Container Starting CUDA-Z... /home/francesco/tmp/CUDA-Z-a3db-49bf-8cb7-059d/cuda-z: error while loading shared libraries: libXrender.so.1: cannot open shared object file: No such file or directory francesco@gig64:~/tmp$ Actually the required lib is available, as shown by my copy into tmp. I don't remember the source of this GNU CUDA-Z tool. Any experience with? I have also met reports of unexciting experience with PCIe 3.0, that is meager or no gain over PCIe 2.0, however it deals of people carrying out games, which is different from NAMD molecular dynamics, where most is done by the GPUs but AT EACH STEP energy has to be calculated by the CPU. I see a package in Debian named 'nvidia-cuda-toolkit'. Does that include that you were looking for? I guess the bandwidthtest isn't built normally. -- Len Sroensen -- To UNSUBSCRIBE, email to debian-amd64-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20131113171328.gg20...@csclub.uwaterloo.ca
Re: upgrade to jessie from wheezy with cuda problems
On Wed, Nov 13, 2013 at 10:32:26AM +0100, Francesco Pietra wrote: My answer seems to have disappeared. I summarize here. modinfo nvidia-curred works well. CUDA libraries are installed. For nvidia-cuda-toolkit, nvidia offers SDK packages for Ubuntu, not for Debian. I don't like to get into troubles with Ubuntu, which, unlike LinuxMINT, is not compatible with Debian. I tried GNU CUDA-Z-07.189.run (don't remember from where it was downloaded). However it does not find the shared libXrender.so.1, even if made available into the same folder of CUDA-Z. Actually root@gig64:/home/francesco# apt-file search libXrender.so.1 libxrender1: /usr/lib/x86_64-linux-gnu/libXrender.so.1 libxrender1: /usr/lib/x86_64-linux-gnu/libXrender.so.1.3.0 libxrender1-dbg: /usr/lib/debug/usr/lib/x86_64-linux-gnu/libXrender.so.1.3.0 root@gig64:/home/francesco# francesco@gig64:~$ echo $PATH /opt/namd2.9_cuda4.0_2012-09-26/bin:/opt/namd2.9_cuda4.0_2012-09-26/bin:/opt/namd2.9_cuda4.0_2012-09-26/bin:/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games:/opt/amber12/bin:/opt/amber10/bin:/opt/UCSF/Chimera64-2012-10-10/bin:/opt/namd2.9_cuda4.0_2012-09-26/bin/namd2:/opt/amber12/bin:/opt/amber10/bin:/opt/UCSF/Chimera64-2012-10-10/bin:/opt/namd2.9_cuda4.0_2012-09-26/bin/namd2:/opt/amber12/bin:/opt/amber10/bin:/opt/UCSF/Chimera64-2012-10-10/bin:/opt/namd2.9_cuda4.0_2012-09-26/bin/namd2 francesco@gig64:~$ Should /usr/lib/x86_64-linux-gnu be put on my path explicitly? The PATH is not for libraries. LD_LIBRARY_PATH is, as is /etc/ld.so.conf stuff. Also is what you downloaded 32 or 64 bit? Try: ldd CUDA-Z-07.189.run See what it is looking for. -- Len Sorensen -- To UNSUBSCRIBE, email to debian-amd64-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20131113171504.gh20...@csclub.uwaterloo.ca
Fwd: upgrade to jessie from wheezy with cuda problems
francesco@gig64:~/tmp$ export LD_LIBRARY_PATH=/usr/lib/x86_64-linux-gnu/ francesco@gig64:~/tmp$ ./CUDA-Z-0.7.189.run CUDA-Z 0.7.189 Container Starting CUDA-Z... /home/francesco/tmp/CUDA-Z-95b0-7943-3edd-827e/cuda-z: error while loading shared libraries: libXrender.so.1: wrong ELF class: ELFCLASS64 francesco@gig64:~/tmp$ -- Forwarded message -- From: Francesco Pietra chiendar...@gmail.com Date: Wed, Nov 13, 2013 at 10:32 AM Subject: Re: upgrade to jessie from wheezy with cuda problems To: Lennart Sorensen lsore...@csclub.uwaterloo.ca Cc: amd64 Debian debian-amd64@lists.debian.org My answer seems to have disappeared. I summarize here. modinfo nvidia-curred works well. CUDA libraries are installed. For nvidia-cuda-toolkit, nvidia offers SDK packages for Ubuntu, not for Debian. I don't like to get into troubles with Ubuntu, which, unlike LinuxMINT, is not compatible with Debian. I tried GNU CUDA-Z-07.189.run (don't remember from where it was downloaded). However it does not find the shared libXrender.so.1, even if made available into the same folder of CUDA-Z. Actually root@gig64:/home/francesco# apt-file search libXrender.so.1 libxrender1: /usr/lib/x86_64-linux-gnu/libXrender.so.1 libxrender1: /usr/lib/x86_64-linux-gnu/libXrender.so.1.3.0 libxrender1-dbg: /usr/lib/debug/usr/lib/x86_64-linux-gnu/libXrender.so.1.3.0 root@gig64:/home/francesco# francesco@gig64:~$ echo $PATH /opt/namd2.9_cuda4.0_2012-09-26/bin:/opt/namd2.9_cuda4.0_2012-09-26/bin:/opt/namd2.9_cuda4.0_2012-09-26/bin:/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games:/opt/amber12/bin:/opt/amber10/bin:/opt/UCSF/Chimera64-2012-10-10/bin:/opt/namd2.9_cuda4.0_2012-09-26/bin/namd2:/opt/amber12/bin:/opt/amber10/bin:/opt/UCSF/Chimera64-2012-10-10/bin:/opt/namd2.9_cuda4.0_2012-09-26/bin/namd2:/opt/amber12/bin:/opt/amber10/bin:/opt/UCSF/Chimera64-2012-10-10/bin:/opt/namd2.9_cuda4.0_2012-09-26/bin/namd2 francesco@gig64:~$ Should /usr/lib/x86_64-linux-gnu be put on my path explicitly? Thanks francesco pietra On Tue, Nov 12, 2013 at 11:37 PM, Lennart Sorensen lsore...@csclub.uwaterloo.ca wrote: On Tue, Nov 12, 2013 at 10:35:53PM +0100, Francesco Pietra wrote: # apt-get --purge remove *legacy* did the job. I wonder how these legacy packages entered the scene while updating/upgrading from a clean wheezy. The bad news are that with the new driver 319.60 there was no acceleration of molecular dynamics for a job of modest size (150K atoms) and slight acceleration (0.12 s/step vs 0.14 s/step) for a heavy job (500K atoms). Weather bringing from PCIe 2.0 (with the 304.xx driver of wheezy) to PCIe 3.0 (with driver 319.60 of jessie) (increasing the bandwidth from GPUs to RAM from 5 to 8GB/s) has not the effect that I hoped on the calculations, or PCIe is still 2.0 with jessie. Now, with cuda 5.0, it should be easy to measure the bandwidth directly. I have to learn how and I'll report about in due course. Now nvidia-smi activates the GPUs for normal work, nvidia-smi -L tells about the GPUs, dpkg -l |grep nvidia shows all 319.60 or 5.0.35-8, the X-server can be started and gnome loaded (startx, gnome-session), nvcc --version gives 5.0, however # modinfo nvidia ERROR: module nvidia not found In analogy with wheezy 3.2.0-4, I expected /lib/modules/3.10-3-amd64/updates/dkms/nvidia.ko Instead, there is /lib/modules/3.10-3-amd64/nvidia/nvidia-current.ko is that a feature of jessie or something wrong? I think it was renamed. No idea why. modinfo nvidia-current should work though. Do you have the cuda libraries for the 319 version installed? I don't play around with GPU computations, but from what I have read it does need a certain size job before the overhead of transfering the data and managing the GPU makse it worthwhile, but for large jobs the high core count and memory bandwidth makes a big difference. -- Len Sorensen
Fwd: upgrade to jessie from wheezy with cuda problems
Sorry, I had not noticed the suggestion, however I had already what inthe meantime became obvious. The executable is said for both 64 and 32 bit but apparently the lib has to be 32. I have no 32, nor multiarch, to avoid complications for a box used for MD only. No luck for me on investigating the bandwidth. thanks francesco pietra -- Forwarded message -- From: Francesco Pietra chiendar...@gmail.com Date: Wed, Nov 13, 2013 at 7:40 PM Subject: Fwd: upgrade to jessie from wheezy with cuda problems To: amd64 Debian debian-amd64@lists.debian.org francesco@gig64:~/tmp$ export LD_LIBRARY_PATH=/usr/lib/x86_64-linux-gnu/ francesco@gig64:~/tmp$ ./CUDA-Z-0.7.189.run CUDA-Z 0.7.189 Container Starting CUDA-Z... /home/francesco/tmp/CUDA-Z-95b0-7943-3edd-827e/cuda-z: error while loading shared libraries: libXrender.so.1: wrong ELF class: ELFCLASS64 francesco@gig64:~/tmp$ -- Forwarded message -- From: Francesco Pietra chiendar...@gmail.com Date: Wed, Nov 13, 2013 at 10:32 AM Subject: Re: upgrade to jessie from wheezy with cuda problems To: Lennart Sorensen lsore...@csclub.uwaterloo.ca Cc: amd64 Debian debian-amd64@lists.debian.org My answer seems to have disappeared. I summarize here. modinfo nvidia-curred works well. CUDA libraries are installed. For nvidia-cuda-toolkit, nvidia offers SDK packages for Ubuntu, not for Debian. I don't like to get into troubles with Ubuntu, which, unlike LinuxMINT, is not compatible with Debian. I tried GNU CUDA-Z-07.189.run (don't remember from where it was downloaded). However it does not find the shared libXrender.so.1, even if made available into the same folder of CUDA-Z. Actually root@gig64:/home/francesco# apt-file search libXrender.so.1 libxrender1: /usr/lib/x86_64-linux-gnu/libXrender.so.1 libxrender1: /usr/lib/x86_64-linux-gnu/libXrender.so.1.3.0 libxrender1-dbg: /usr/lib/debug/usr/lib/x86_64-linux-gnu/libXrender.so.1.3.0 root@gig64:/home/francesco# francesco@gig64:~$ echo $PATH /opt/namd2.9_cuda4.0_2012-09-26/bin:/opt/namd2.9_cuda4.0_2012-09-26/bin:/opt/namd2.9_cuda4.0_2012-09-26/bin:/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games:/opt/amber12/bin:/opt/amber10/bin:/opt/UCSF/Chimera64-2012-10-10/bin:/opt/namd2.9_cuda4.0_2012-09-26/bin/namd2:/opt/amber12/bin:/opt/amber10/bin:/opt/UCSF/Chimera64-2012-10-10/bin:/opt/namd2.9_cuda4.0_2012-09-26/bin/namd2:/opt/amber12/bin:/opt/amber10/bin:/opt/UCSF/Chimera64-2012-10-10/bin:/opt/namd2.9_cuda4.0_2012-09-26/bin/namd2 francesco@gig64:~$ Should /usr/lib/x86_64-linux-gnu be put on my path explicitly? Thanks francesco pietra On Tue, Nov 12, 2013 at 11:37 PM, Lennart Sorensen lsore...@csclub.uwaterloo.ca wrote: On Tue, Nov 12, 2013 at 10:35:53PM +0100, Francesco Pietra wrote: # apt-get --purge remove *legacy* did the job. I wonder how these legacy packages entered the scene while updating/upgrading from a clean wheezy. The bad news are that with the new driver 319.60 there was no acceleration of molecular dynamics for a job of modest size (150K atoms) and slight acceleration (0.12 s/step vs 0.14 s/step) for a heavy job (500K atoms). Weather bringing from PCIe 2.0 (with the 304.xx driver of wheezy) to PCIe 3.0 (with driver 319.60 of jessie) (increasing the bandwidth from GPUs to RAM from 5 to 8GB/s) has not the effect that I hoped on the calculations, or PCIe is still 2.0 with jessie. Now, with cuda 5.0, it should be easy to measure the bandwidth directly. I have to learn how and I'll report about in due course. Now nvidia-smi activates the GPUs for normal work, nvidia-smi -L tells about the GPUs, dpkg -l |grep nvidia shows all 319.60 or 5.0.35-8, the X-server can be started and gnome loaded (startx, gnome-session), nvcc --version gives 5.0, however # modinfo nvidia ERROR: module nvidia not found In analogy with wheezy 3.2.0-4, I expected /lib/modules/3.10-3-amd64/updates/dkms/nvidia.ko Instead, there is /lib/modules/3.10-3-amd64/nvidia/nvidia-current.ko is that a feature of jessie or something wrong? I think it was renamed. No idea why. modinfo nvidia-current should work though. Do you have the cuda libraries for the 319 version installed? I don't play around with GPU computations, but from what I have read it does need a certain size job before the overhead of transfering the data and managing the GPU makse it worthwhile, but for large jobs the high core count and memory bandwidth makes a big difference. -- Len Sorensen
Re: Fwd: upgrade to jessie from wheezy with cuda problems
On Wed, Nov 13, 2013 at 07:40:10PM +0100, Francesco Pietra wrote: francesco@gig64:~/tmp$ export LD_LIBRARY_PATH=/usr/lib/x86_64-linux-gnu/ That is unnecesary. That is already in the library path. The local directory is not. Windows implicitly looks in the current directory for files, linux (and almost all other systems) does not. hence: export LD_LIBRARY_PATH=. (. for current directory), or LD_LIBRARY_PATH=/tmp if that is where you put the library you were trying. francesco@gig64:~/tmp$ ./CUDA-Z-0.7.189.run CUDA-Z 0.7.189 Container Starting CUDA-Z... /home/francesco/tmp/CUDA-Z-95b0-7943-3edd-827e/cuda-z: error while loading shared libraries: libXrender.so.1: wrong ELF class: ELFCLASS64 francesco@gig64:~/tmp$ What does 'file ./CUDA-Z-0.7.189.run' say? -- Len Sorensen -- To UNSUBSCRIBE, email to debian-amd64-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20131113185253.gi20...@csclub.uwaterloo.ca
Re: Fwd: upgrade to jessie from wheezy with cuda problems
Em 13-11-2013 16:40, Francesco Pietra escreveu: francesco@gig64:~/tmp$ export LD_LIBRARY_PATH=/usr/lib/x86_64-linux-gnu/ francesco@gig64:~/tmp$ ./CUDA-Z-0.7.189.run CUDA-Z 0.7.189 Container Starting CUDA-Z... /home/francesco/tmp/CUDA-Z-95b0-7943-3edd-827e/cuda-z: error while loading shared libraries: libXrender.so.1: wrong ELF class: ELFCLASS64 francesco@gig64:~/tmp$ Hi Francesco . is CUDA-Z a 32-bit binary ? what is the output of this command : $ file /home/francesco/tmp/CUDA-Z-95b0-7943-3edd-827e/cuda-z -- To UNSUBSCRIBE, email to debian-amd64-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/5283d078.6010...@gmail.com
Re: Fwd: upgrade to jessie from wheezy with cuda problems
francesco@gig64:~$ file /home/francesco/tmp/CUDA-Z-95b0-7943-3edd-827e/cuda-z /home/francesco/tmp/CUDA-Z-95b0-7943-3edd-827e/cuda-z: ERROR: cannot open `/home/francesco/tmp/CUDA-Z-95b0-7943-3edd-827e/cuda-z' (No such file or directory) francesco@gig64:~$ On Wed, Nov 13, 2013 at 8:18 PM, Fabricio Cannini fcann...@gmail.comwrote: Em 13-11-2013 16:40, Francesco Pietra escreveu: francesco@gig64:~/tmp$ export LD_LIBRARY_PATH=/usr/lib/x86_64-linux-gnu/ francesco@gig64:~/tmp$ ./CUDA-Z-0.7.189.run CUDA-Z 0.7.189 Container Starting CUDA-Z... /home/francesco/tmp/CUDA-Z-95b0-7943-3edd-827e/cuda-z: error while loading shared libraries: libXrender.so.1: wrong ELF class: ELFCLASS64 francesco@gig64:~/tmp$ Hi Francesco . is CUDA-Z a 32-bit binary ? what is the output of this command : $ file /home/francesco/tmp/CUDA-Z-95b0-7943-3edd-827e/cuda-z -- To UNSUBSCRIBE, email to debian-amd64-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/5283d078.6010...@gmail.com
Re: Fwd: upgrade to jessie from wheezy with cuda problems
What does 'file ./CUDA-Z-0.7.189.run' say? francesco@gig64:~/tmp$ file ./CUDA-Z-0.7.189.run ./CUDA-Z-0.7.189.run: data francesco@gig64:~/tmp$ On Wed, Nov 13, 2013 at 7:52 PM, Lennart Sorensen lsore...@csclub.uwaterloo.ca wrote: On Wed, Nov 13, 2013 at 07:40:10PM +0100, Francesco Pietra wrote: francesco@gig64:~/tmp$ export LD_LIBRARY_PATH=/usr/lib/x86_64-linux-gnu/ That is unnecesary. That is already in the library path. The local directory is not. Windows implicitly looks in the current directory for files, linux (and almost all other systems) does not. hence: export LD_LIBRARY_PATH=. (. for current directory), or LD_LIBRARY_PATH=/tmp if that is where you put the library you were trying. francesco@gig64:~/tmp$ ./CUDA-Z-0.7.189.run CUDA-Z 0.7.189 Container Starting CUDA-Z... /home/francesco/tmp/CUDA-Z-95b0-7943-3edd-827e/cuda-z: error while loading shared libraries: libXrender.so.1: wrong ELF class: ELFCLASS64 francesco@gig64:~/tmp$ What does 'file ./CUDA-Z-0.7.189.run' say? -- Len Sorensen
Re: Fwd: upgrade to jessie from wheezy with cuda problems
On Wed, Nov 13, 2013 at 10:53:30PM +0100, Francesco Pietra wrote: francesco@gig64:~/tmp$ file ./CUDA-Z-0.7.189.run ./CUDA-Z-0.7.189.run: data francesco@gig64:~/tmp$ OK that's weird. I expected to see x86 32 or 64bit binary. Seems to be a shell scripts with compressed code in it. Yuck. :) -- Len Sorensen -- To UNSUBSCRIBE, email to debian-amd64-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20131113224347.gj20...@csclub.uwaterloo.ca
Re: Fwd: upgrade to jessie from wheezy with cuda problems
On Wed, Nov 13, 2013 at 05:43:47PM -0500, Lennart Sorensen wrote: On Wed, Nov 13, 2013 at 10:53:30PM +0100, Francesco Pietra wrote: francesco@gig64:~/tmp$ file ./CUDA-Z-0.7.189.run ./CUDA-Z-0.7.189.run: data francesco@gig64:~/tmp$ OK that's weird. I expected to see x86 32 or 64bit binary. Seems to be a shell scripts with compressed code in it. Yuck. :) OK I got it running. It is a 32bit binary. I had to install these: ii libcuda1:i386 331.20-1i386 NVIDIA CUDA runtime library ii libcudart5.0:i386 5.0.35-8i386 NVIDIA CUDA runtime library ii libgl1-nvidia-glx:i386331.20-1i386 NVIDIA binary OpenGL libraries ii libstdc++6:i386 4.8.2-4 i386 GNU Standard C++ Library v3 ii libxrender1:i386 1:0.9.8-1 i386 X Rendering Extension client library ii zlib1g:i386 1:1.2.8.dfsg-1 i386 compression library - runtime Then I was able to run it. No messing with LD_LIBRARY_PATH or anything. To install :i386 packages you first have to enable multiarch support with dpkg and run apt-get update. So something like: dpkg --add-architecture i386 apt-get update apt-get install libcuda1:i386 libcudart5.0:i386 libgl1-nvidia-glx:i386 libstdc++6:i386 libxrender1:i386 zlib1g:i386 Don't worry about the exact versions, since I am running unstable+experimental. You don;t need to do that to get it working. For your 64bit code you probably need libcuda1 libcudart5.0 and such installed in the 64bit version. -- Len Sorensen -- To UNSUBSCRIBE, email to debian-amd64-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20131114023334.gk20...@csclub.uwaterloo.ca
Direkt vom Baum auf Ihren Tisch in unter 48 Stunden
PUBLI NEWS NATURVALENCIA Wenn nicht, diese Informationen, folgen Sie bitte diesem Link NALE3687 Warum auf das Gesündeste verzichten? Genießen Sie die besten Orangen des Mittelmeers, direkt vom Baum auf Ihren Tisch in unter 48 Stunden. Zum rechten Zeitpunkt geerntet. Ohne Eile. Sie schmecken den Unterschied! Wenn Sie mehr NaturValencia Nachrichten möchtest, klicke hier und wird automatisch gelöscht werden. Vielen Dank.
upgrade to jessie from wheezy with cuda problems
Hello: I decided to try jessie to get PCIe 3.0 with a recent nvidia driver, thus upgrading from wheezy. wheezy was uname -r 3.2.0-4-amd64 nvidia-smi 304.88 nvcc --version 4.2 (the latter is also the version at which the molecular dynamics code was compiled, and used without calling the X-server) Following aptitude update aptitude-upgrade a number of dependecies related to gnome were not met (evolution-common lbfolks25 gnome-panel gnome-shell gnome-theme-extras gnome-theme-standard libreoffice-evolution). This notwithstanding, I decided to upgrade. After rebooting to get linux matching with nvidia: nvcc --version 5.0 uname -r 3.10-3-amd64 nvidia-smi the nvidia kernel module has version 304.108 but the nvidia driver component has version 319.60. Driver 319.6 is just what I wanted. Now, how best fix the problems? Install linux image 3.2? In the past I tried dist-upgrade, getting into devastating problems. thanks francesco pietra PS I was advised that debian is getting bounces from my address above. If so, please try my institutional address francesco.pie...@accademialucchese.it
Re: upgrade to jessie from wheezy with cuda problems
On Tue, Nov 12, 2013 at 03:54:32PM +0100, Francesco Pietra wrote: Hello: I decided to try jessie to get PCIe 3.0 with a recent nvidia driver, thus upgrading from wheezy. wheezy was uname -r 3.2.0-4-amd64 nvidia-smi 304.88 nvcc --version 4.2 (the latter is also the version at which the molecular dynamics code was compiled, and used without calling the X-server) Following aptitude update aptitude-upgrade a number of dependecies related to gnome were not met (evolution-common lbfolks25 gnome-panel gnome-shell gnome-theme-extras gnome-theme-standard libreoffice-evolution). This notwithstanding, I decided to upgrade. After rebooting to get linux matching with nvidia: nvcc --version 5.0 uname -r 3.10-3-amd64 nvidia-smi the nvidia kernel module has version 304.108 but the nvidia driver component has version 319.60. Driver 319.6 is just what I wanted. Now, how best fix the problems? Install linux image 3.2? In the past I tried dist-upgrade, getting into devastating problems. Do you have nvidia-kernel-dkms installed? -- Len Sorensen -- To UNSUBSCRIBE, email to debian-amd64-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20131112145937.gc20...@csclub.uwaterloo.ca
Re: upgrade to jessie from wheezy with cuda problems
On Tue, Nov 12, 2013 at 05:22:18PM +0100, Francesco Pietra wrote: Yes. Also, # apt-get remove nvidia-kernel-dkms # apt-get install nvidia-kernel-dkms (which, in the year 2011, served to clear the driver at /lib/modules/2.6.38-2-amd64/updates/dkms. But now the kernel was 3.2.) left the issue unaltered. # modinfo nvidia ERROR: module nvidia not found $ dpkg -l |grep nvidia |less shows libl1-nvidia-glx:amd64 319.60 and libg1-nvidia-legacy-304xx--glx:amd64 304.108-4 NVIDIA metapackage rc nvidia-glx 304.88-1-deb7u1 nvidia-legacy-304xx-driver 304.108-4 nvidia-legacy-304xx-kernel-dkms 304.108-4 nvidia-settings-legacy-303xx 304.108-2 xserver-xorg-video-nvidia-legacy-304xx304.108-4 Everything else 319.60-1 and cuda 5.0 I don't understand why these 304xx are threatening. I had also run # nvidia-xconfig I think you should remove all packages with legacy-304xx in the name, and install the current ones (nvidia-kernel-dkms, nvidia-glx, etc). legacy-304xx will never move beyond version 304.xx after all as the name implies. -- Len Sorensen -- To UNSUBSCRIBE, email to debian-amd64-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20131112165947.ge20...@csclub.uwaterloo.ca
Re: upgrade to jessie from wheezy with cuda problems
# apt-get --purge remove *legacy* did the job. I wonder how these legacy packages entered the scene while updating/upgrading from a clean wheezy. The bad news are that with the new driver 319.60 there was no acceleration of molecular dynamics for a job of modest size (150K atoms) and slight acceleration (0.12 s/step vs 0.14 s/step) for a heavy job (500K atoms). Weather bringing from PCIe 2.0 (with the 304.xx driver of wheezy) to PCIe 3.0 (with driver 319.60 of jessie) (increasing the bandwidth from GPUs to RAM from 5 to 8GB/s) has not the effect that I hoped on the calculations, or PCIe is still 2.0 with jessie. Now, with cuda 5.0, it should be easy to measure the bandwidth directly. I have to learn how and I'll report about in due course. Now nvidia-smi activates the GPUs for normal work, nvidia-smi -L tells about the GPUs, dpkg -l |grep nvidia shows all 319.60 or 5.0.35-8, the X-server can be started and gnome loaded (startx, gnome-session), nvcc --version gives 5.0, however # modinfo nvidia ERROR: module nvidia not found In analogy with wheezy 3.2.0-4, I expected /lib/modules/3.10-3-amd64/updates/dkms/nvidia.ko Instead, there is /lib/modules/3.10-3-amd64/nvidia/nvidia-current.ko is that a feature of jessie or something wrong? Thanks a lot for advice. francesco pietra. On Tue, Nov 12, 2013 at 5:59 PM, Lennart Sorensen lsore...@csclub.uwaterloo.ca wrote: On Tue, Nov 12, 2013 at 05:22:18PM +0100, Francesco Pietra wrote: Yes. Also, # apt-get remove nvidia-kernel-dkms # apt-get install nvidia-kernel-dkms (which, in the year 2011, served to clear the driver at /lib/modules/2.6.38-2-amd64/updates/dkms. But now the kernel was 3.2.) left the issue unaltered. # modinfo nvidia ERROR: module nvidia not found $ dpkg -l |grep nvidia |less shows libl1-nvidia-glx:amd64 319.60 and libg1-nvidia-legacy-304xx--glx:amd64 304.108-4 NVIDIA metapackage rc nvidia-glx 304.88-1-deb7u1 nvidia-legacy-304xx-driver 304.108-4 nvidia-legacy-304xx-kernel-dkms 304.108-4 nvidia-settings-legacy-303xx 304.108-2 xserver-xorg-video-nvidia-legacy-304xx304.108-4 Everything else 319.60-1 and cuda 5.0 I don't understand why these 304xx are threatening. I had also run # nvidia-xconfig I think you should remove all packages with legacy-304xx in the name, and install the current ones (nvidia-kernel-dkms, nvidia-glx, etc). legacy-304xx will never move beyond version 304.xx after all as the name implies. -- Len Sorensen
Re: upgrade to jessie from wheezy with cuda problems
On Tue, Nov 12, 2013 at 10:35:53PM +0100, Francesco Pietra wrote: # apt-get --purge remove *legacy* did the job. I wonder how these legacy packages entered the scene while updating/upgrading from a clean wheezy. The bad news are that with the new driver 319.60 there was no acceleration of molecular dynamics for a job of modest size (150K atoms) and slight acceleration (0.12 s/step vs 0.14 s/step) for a heavy job (500K atoms). Weather bringing from PCIe 2.0 (with the 304.xx driver of wheezy) to PCIe 3.0 (with driver 319.60 of jessie) (increasing the bandwidth from GPUs to RAM from 5 to 8GB/s) has not the effect that I hoped on the calculations, or PCIe is still 2.0 with jessie. Now, with cuda 5.0, it should be easy to measure the bandwidth directly. I have to learn how and I'll report about in due course. Now nvidia-smi activates the GPUs for normal work, nvidia-smi -L tells about the GPUs, dpkg -l |grep nvidia shows all 319.60 or 5.0.35-8, the X-server can be started and gnome loaded (startx, gnome-session), nvcc --version gives 5.0, however # modinfo nvidia ERROR: module nvidia not found In analogy with wheezy 3.2.0-4, I expected /lib/modules/3.10-3-amd64/updates/dkms/nvidia.ko Instead, there is /lib/modules/3.10-3-amd64/nvidia/nvidia-current.ko is that a feature of jessie or something wrong? I think it was renamed. No idea why. modinfo nvidia-current should work though. Do you have the cuda libraries for the 319 version installed? I don't play around with GPU computations, but from what I have read it does need a certain size job before the overhead of transfering the data and managing the GPU makse it worthwhile, but for large jobs the high core count and memory bandwidth makes a big difference. -- Len Sorensen -- To UNSUBSCRIBE, email to debian-amd64-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20131112223724.gf20...@csclub.uwaterloo.ca
Fwd: nvidia cuda driver for PCIe 3.0 with amd64
To set my question more specifically, does upgrading from amd64 wheezy to amd64 jessie bring a nvidia driver capable of PCIexpress 3.0 with ivy bridge? If so, is update/upgrade enough or a suitable kernel should also be installed? By using distupgrade I had unpleasant experience in the past, of a huge variety of applications installed, when my interest is totally out of graphic interfaces, which can not be used for MD with GPUs. Thank so much. It is a pity to run MD with GPUs at the rate allowed by PCIe 2.0, when the hardware should allow PCIe 3.0 (eight vs five) Cheers francesco pietra -- Forwarded message -- From: Francesco Pietra chiendar...@gmail.com Date: Nov 10, 2013 7:42 AM Subject: nvidia cuda driver for PCIe 3.0 with amd64 To: amd64 Debian debian-amd64@lists.debian.org Cc: Hello In motherboard Gigabyte X79-UD3 I have replaced sandy i7-3930 with ivy i7-4930K (and increased RAM speed to 1866MHz) in view of activating PCIe 3.0 between RAM and the two GTX-680 cards, both on 16 lanes. As expected at current cuda driver 304.88 with amd64 wheezy, there was no speed increase in executing parallelized molecular dynamics (NAMD2.9 code, compiled at cuda 4, and running without the X-server). Both GPUs are working correctly, each one sharing the parts of the protein assigned to them by the code, both GPUs engaging the same amount of memory. As far as I know, nvidia PCIe 3.0 worked with 295.33 drivers under linux, but then nvidia disabled it from 295.xx to (at least) 310.xx. What could I do now to get PDCIe 3.0? (a) Upgrading to testing, if it is true that nvidia cuda drivers there (331.xx I believe) enable PCIe 3.0. This would not be the best for me in view of stability. (b) Backporting testing nvidia drivers to wheezy. Is that possible? Thanks for advice francesco pietra PS: in carrying out the above benchmark, which is provided by NAMD itself, I selected both a light job (small protein) and a very heavy job (large protein in much water). Only in the latter case, the new ivy configuration afforded advantage, albeit as marginal as 0.12 s/step instead of 0.14 s/step. The higher RAM speed gave no advantage. Clearly, there is a bottleneck between the GPUs and RAM with both the sandy and the ivy hardware at driver 304.xx.
BTS tags/pseudopackages for ports [Was: Re: Potential issues for most ports]
On Tue, 05 Nov 2013, Don Armstrong wrote: In any event, if a few active porters wouldn't mind creating a wishlist bug against bugs.debian.org for this with a suggested course of action, I'd appreciate it. Assuming there is no significant disagreement about that course of action, I'd like to implement it within a week or so. If someone has filed a wishlist bug, I've missed it. -- Don Armstrong http://www.donarmstrong.com I really wanted to talk to her. I just couldn't find an algorithm that fit. -- Peter Watts _Blindsight_ p294 -- To UNSUBSCRIBE, email to debian-amd64-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/2013181711.gv9...@rzlab.ucr.edu
nvidia cuda driver for PCIe 3.0 with amd64
Hello In motherboard Gigabyte X79-UD3 I have replaced sandy i7-3930 with ivy i7-4930K (and increased RAM speed to 1866MHz) in view of activating PCIe 3.0 between RAM and the two GTX-680 cards, both on 16 lanes. As expected at current cuda driver 304.88 with amd64 wheezy, there was no speed increase in executing parallelized molecular dynamics (NAMD2.9 code, compiled at cuda 4, and running without the X-server). Both GPUs are working correctly, each one sharing the parts of the protein assigned to them by the code, both GPUs engaging the same amount of memory. As far as I know, nvidia PCIe 3.0 worked with 295.33 drivers under linux, but then nvidia disabled it from 295.xx to (at least) 310.xx. What could I do now to get PDCIe 3.0? (a) Upgrading to testing, if it is true that nvidia cuda drivers there (331.xx I believe) enable PCIe 3.0. This would not be the best for me in view of stability. (b) Backporting testing nvidia drivers to wheezy. Is that possible? Thanks for advice francesco pietra PS: in carrying out the above benchmark, which is provided by NAMD itself, I selected both a light job (small protein) and a very heavy job (large protein in much water). Only in the latter case, the new ivy configuration afforded advantage, albeit as marginal as 0.12 s/step instead of 0.14 s/step. The higher RAM speed gave no advantage. Clearly, there is a bottleneck between the GPUs and RAM with both the sandy and the ivy hardware at driver 304.xx.
Re: Qt5 switching qreal from float to double on arm*
On Thu, Nov 07, 2013 at 02:46:27PM -0300, Lisandro Damián Nicanor Pérez Meyer wrote: - If we decide to do the change in Qt5, it will be *without* soname bump. Yes, I know many of you will think of this as **ugly**, but so far means 3 binNMUs per arch. Now if this is not acceptable, then no change will be made, because I won't change Qt5's SONAME. What is your plan to support partial upgrades? BinNMUs can require new Qt versions to be installed, but Qt can be upgraded independently to the newer version, causing the rdepends to crash. This can potentially be solved by Breaks, but it still breaks assumptions of people using Debian in that such ABI breaks will be communicated through SONAME bumps. And the old lib will not even be coinstallable. (Of course a good time to do such changes are in fact SONAME bumps, but I realize that this won't happen for Qt for quite some time.) Kind regards Philipp Kern signature.asc Description: Digital signature
Re: Qt5 switching qreal from float to double on arm*
On Sat, Nov 02, 2013, Lisandro Damián Nicanor Pérez Meyer wrote: Hi! Starting from Qt 5.2.0 (most probably from rc1 and definitely not from beta1 currently in experimental) Qt5 will switch qreal from float to double on arm*. We have the option to keep some archs in float by passing a compilation parameter. I've done so for armel and sh4, so only armhf will switch to double. Of course we are still on time to discuss this, and this is the reason of this mail. What do you think WRT the above changes? First, thanks a lot for the heads up on this. qreal being float instead of double on ARM was the source of a bunch of work for ARM porters in the past; now I have these worries/questions: * switching it back might imply some new porting work (in the case where the patches were something #if ARM use float #else use double); this might be particularly painful if armel and armhf have different definitions. Maybe there's a nice define #QREAL_IS_FLOAT or something to help with this. * what about arm64? sounds like this one should be double from the start; not sure what it is right now * when you say you've changed armel and sh4 to keep using float, is this Debian-specific? Not sure we want a delta with upstream on this kind of stuff. Would it not work at all to use double, or would it just be slow? I'd rather have it slow for people using big software on slow arches rather than keeping a delta; it sounds like we do a SONAME transition no matter what anyway * what's the point in qreal anyway? can't we just switch everything to float or double? sounds like software should know what kind of level of precision it needs in the first place; e.g. if it's a scale in some UI, then either float or double is enough, but it's not an arch specific decision Thanks again for raising this! -- Loïc Minier -- To UNSUBSCRIBE, email to debian-amd64-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20131107171818.gb12...@bee.dooz.org
Re: Qt5 switching qreal from float to double on arm*
On Thursday 07 November 2013 18:18:18 you wrote: On Sat, Nov 02, 2013, Lisandro Damián Nicanor Pérez Meyer wrote: Hi! Starting from Qt 5.2.0 (most probably from rc1 and definitely not from beta1 currently in experimental) Qt5 will switch qreal from float to double on arm*. We have the option to keep some archs in float by passing a compilation parameter. I've done so for armel and sh4, so only armhf will switch to double. Of course we are still on time to discuss this, and this is the reason of this mail. What do you think WRT the above changes? First, thanks a lot for the heads up on this. Thank you too for replying :) qreal being float instead of double on ARM was the source of a bunch of work for ARM porters in the past; now I have these worries/questions: * switching it back might imply some new porting work (in the case where the patches were something #if ARM use float #else use double); this might be particularly painful if armel and armhf have different definitions. Maybe there's a nice define #QREAL_IS_FLOAT or something to help with this. Don't forget we are talking about *just* Qt5 here, *not* Qt4. We only have 3 apps building against Qt5 right now. If apps switch to Qt5 they will surely find some bumps, so this can be managed. * what about arm64? sounds like this one should be double from the start; not sure what it is right now I have not added any provisions to arm64, so with the next 5.2.0 [rc/final] upload it will switch to double. We are still on time if something needs a fix here. * when you say you've changed armel and sh4 to keep using float, is this Debian-specific? Not sure we want a delta with upstream on this kind of stuff. Would it not work at all to use double, or would it just be slow? I'd rather have it slow for people using big software on slow arches rather than keeping a delta; it sounds like we do a SONAME transition no matter what anyway Now this *will* be messy. I have asked upstream [0] and so far haven't got any explicit reply from other distro's maintainers. [0] http://lists.qt-project.org/pipermail/development/2013-November/014017.html But, according to [1]: I should also point out that this option now allows selecting qreal to be float on other platforms, besides ARM. That's why I'm still spamming debian-ports ;) [1] http://lists.qt-project.org/pipermail/development/2013-November/014017.html So: - We don't know yet what other distros are going to do. - If we decide to do the change in Qt5, it will be *without* soname bump. Yes, I know many of you will think of this as **ugly**, but so far means 3 binNMUs per arch. Now if this is not acceptable, then no change will be made, because I won't change Qt5's SONAME. * what's the point in qreal anyway? can't we just switch everything to float or double? sounds like software should know what kind of level of precision it needs in the first place; e.g. if it's a scale in some UI, then either float or double is enough, but it's not an arch specific decision I really don't know, it was already there when I started using Qt back in Qt3's final days ;-) But I *do* know that if people want it gone, they will need to wait until Qt6 and provide the necessary patches :-/ Hope that helps, Lisandro. -- Lisandro Damián Nicanor Pérez Meyer http://perezmeyer.com.ar/ http://perezmeyer.blogspot.com/ signature.asc Description: This is a digitally signed message part.
Re: Qt5 switching qreal from float to double on arm*
On Thursday 07 November 2013 18:55:31 Loïc Minier wrote: On Thu, Nov 07, 2013, Lisandro Damián Nicanor Pérez Meyer wrote: - We don't know yet what other distros are going to do. IMO we shouldn't have distro-specific patching for this kind of stuff; it seems to commonly impact apps (which should be using qreal instead of assuming qreal is double) way too commonly, and we want binaries to be compatible between distros, so diverging from upstream seems a really bad idea. The problem is the can of worms it has been opened: now we have the *chance* to choose, so ideally we need maintainers from most distros cooperating to keep SONAME and ABI the same. Let's hope maintainers from other distros stand up. -- Lisandro Damián Nicanor Pérez Meyer http://perezmeyer.com.ar/ http://perezmeyer.blogspot.com/ signature.asc Description: This is a digitally signed message part.
Re: Bits from the Release Team (Jessie freeze info)
Am 29.10.2013 17:48, schrieb Ian Jackson: (Mind you, I have my doubts about a process which counts people promising to do work - it sets up some rather unfortunate incentives. I guess it's easier to judge and more prospective than a process which attempts to gauge whether the work has been done well enough.) As an example I remember having received several complains from e.g. the GCC maintainers in regards to the state of gcc on various ports[1]. Here I would suspect a patch would be sufficient without needing to actually NMU gcc to get the fix in. There are also stuff like the port concerns from DSA that attention. Right. that's not enough. GCC has some primary and some secondary release architectures. Toolchain support for primary architectures in Debian should be waived, for the secondary and other architectures, Debian needs somebody who is maintaining the relationship between Debian and upstream. Surprisingly this is the case for many non-release Debian architectures like kfreebsd, the Hurd, alpha, hppa, m68k, but not for Debian release architectures like s390, sparc, ia64 and mips*. So we really need somebody to care about this, where the port is considered a secondary citizen or no citizen, or we should demote a port to the ports archive. Matthias -- To UNSUBSCRIBE, email to debian-amd64-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/527c2170.8020...@debian.org
Re: Potential issues for most ports (Was: Re: Bits from the Release Team (Jessie freeze info))
On Tue, Nov 05, 2013 at 08:53:05AM +0100, Niels Thykier wrote: [1] I certainly wouldn't have space for something like this: http://en.wikipedia.org/wiki/File:Z800_2066_JKU.jpeg (and much less the money. Yeah I know that is technically not an s390, but as I understand it, an s390 should be around that size) That is in fact a s390, and pretty much the smallest of the zSeries you can find. You wouldn't be able to do anything with it even if you got it, though - it doesn't have internal storage at all (no Mainframe has, except the previous-generation Multiprise 3000 series), and requires external FICON/ESCON SAN storage to boot/operate. So you'd have to take a big clunky enterprise array of disks as well - just another full rack, if you're lucky. I was offered one of these z800 at some point, and had to pass on it too. Oh, and then there's the licensing stuff... chances of getting the required IBM assistance to get it (re)installed are about on par with Justin Bieber's chances of getting elected as President. There's an emulator (hercules) which can run zSeries operating systems on top of Linux, if you can get your hands on those. Anyway, sorry for going offtopic. :-) Lennert signature.asc Description: Digital signature
Re: Potential issues for most ports (Was: Re: Bits from the Release Team (Jessie freeze info))
Niels Thykier writes (Re: Potential issues for most ports (Was: Re: Bits from the Release Team (Jessie freeze info))): On 2013-11-03 16:03, Steven Chamberlain wrote: http://udd.debian.org/bugs.cgi?release=jessie_or_sidmerged=ignfnewerval=7kfreebsd=1sortby=severitysorto=desccseverity=1ctags=1 Actually, I meant a real BTS page (e.g. like [1]) rather than just a list of tagged bugs. The list of tagged bugs definitely have it uses, but it does not give me an overview of which bugs should be fixed by the maintainer of the given package and which the porters should fix. I think this would be a good idea. If the psuedo-package had a predictable name which depended only on the architecture, even better. Ian. -- To UNSUBSCRIBE, email to debian-amd64-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/21113.13532.963985.569...@chiark.greenend.org.uk
Re: Potential issues for most ports (Was: Re: Bits from the Release Team (Jessie freeze info))
On Tue, 05 Nov 2013, Niels Thykier wrote: In this regard; I am guilty of filing some those bugs without tagging them. Honestly, adding the tags get a bit in the way right now. If a package FTBFS on 4 architectures, I have to dig up 3-4 different usertags (with different user) and associate it with the bug. This sounds like a case where we should turn these usertags into fully fledged tags. [Or alternatively, they should just be made usertags under the debian-po...@lists.debian.org user or similar.] I'm OK with assisting with either, but I need to know which solution porters would prefer. -- Don Armstrong http://www.donarmstrong.com For those who understand, no explanation is necessary. For those who do not, none is possible. -- To UNSUBSCRIBE, email to debian-amd64-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20131105183439.gy9...@rzlab.ucr.edu
Re: Potential issues for most ports (Was: Re: Bits from the Release Team (Jessie freeze info))
On Tue, 05 Nov 2013, Don Armstrong wrote: On Tue, 05 Nov 2013, Niels Thykier wrote: In this regard; I am guilty of filing some those bugs without tagging them. Honestly, adding the tags get a bit in the way right now. If a package FTBFS on 4 architectures, I have to dig up 3-4 different usertags (with different user) and associate it with the bug. This sounds like a case where we should turn these usertags into fully fledged tags. [Or alternatively, they should just be made usertags under the debian-po...@lists.debian.org user or similar.] I would also be OK with creating a pseudopackage as well as Ian suggested. [Or multiple pseudopackages.] Something like i386.ports.debian.org or similar would work, with each current port getting a pseudopackage, and the maintainer of the pseudopackage being the ports list. -- Don Armstrong http://www.donarmstrong.com America was far better suited to be the World's Movie Star. The world's tequila-addled pro-league bowler. The world's acerbic bi-polar stand-up comedian. Anything but a somber and tedious nation of socially responsible centurions. -- Bruce Sterling, _Distraction_ p122 -- To UNSUBSCRIBE, email to debian-amd64-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20131105185031.gz9...@rzlab.ucr.edu
Re: Potential issues for most ports (Was: Re: Bits from the Release Team (Jessie freeze info))
Hi, On 05/11/13 18:50, Don Armstrong wrote: On Tue, 05 Nov 2013, Don Armstrong wrote: This sounds like a case where we should turn these usertags into fully fledged tags. [Or alternatively, they should just be made usertags under the debian-po...@lists.debian.org user or similar.] Either of those sounds good. Fully-fledged tags would be the easiest for most reporters to remember to use, but I wonder if this pollutes the tag namespace. [Or multiple pseudopackages.] Something like i386.ports.debian.org or similar would work, with each current port getting a pseudopackage, and the maintainer of the pseudopackage being the ports list. Would that be only for generic issues with a port, not specific to a package? I doubt this would be used much. These bugs might typically be reassigned to kernel packages or eglibc anyway. Regards, -- Steven Chamberlain ste...@pyro.eu.org -- To UNSUBSCRIBE, email to debian-amd64-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/527949c5.8040...@pyro.eu.org
Re: Potential issues for most ports (Was: Re: Bits from the Release Team (Jessie freeze info))
On Tue, 05 Nov 2013, Wouter Verhelst wrote: Well, I did ask for the creation of port-specific tags back at debconf8 (if I'm not mistaken), but you told me to go for usertags instead ;-) Sounds familiar. Usertags have the advantage of not requiring me to do any work. But presumably at the time I hadn't thought of the difficulties of coordinating all of the different usertags between porters. Yes, I think that's a good idea; it would avoid issues where maintainers are waiting on porters and vice versa, since the reassigning of a bug to a port pseudopackage would make it clear who's waiting for whom. Additionally, it would allow porters to have a todo list of things that need to be done for their port but aren't specific to any one package (or of which the root cause hasn't been found yet, e.g., recently compiled binaries segfault, but we don't know why yet) If you're going down this road, I would appreciate it if ports listed on debian-ports.org would also be getting pseudopackages. Since they would all be under the same ports.debian.org (or similar) namespace, I wouldn't have a problem with it. [My main concern about pseudopackages is polluting the package namespace; since I can't imagine anyone ever wanting to create a package called someport.ports.debian.org for a sane reason, that shouldn't be a big deal.] It would also be possible (in the meantime) for bugs to be assigned to both the port-specific pseudopackage, and the original package which spawned the bug. In any event, if a few active porters wouldn't mind creating a wishlist bug against bugs.debian.org for this with a suggested course of action, I'd appreciate it. Assuming there is no significant disagreement about that course of action, I'd like to implement it within a week or so. -- Don Armstrong http://www.donarmstrong.com PowerPoint is symptomatic of a certain type of bureaucratic environment: one typified by interminable presentations with lots of fussy little bullet-points and flashy dissolves and soundtracks masked into the background, to try to convince the audience that the goon behind the computer has something significant to say. -- Charles Stross _The Jennifer Morgue_ p33 -- To UNSUBSCRIBE, email to debian-amd64-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20131105201345.ga9...@rzlab.ucr.edu
Re: Qt5 switching qreal from float to double on arm*
Note: readding p-k-t@ and debian-ports@... On Tuesday 05 November 2013 19:22:30 peter green wrote: Lisandro Damián Nicanor Pérez Meyer wrote: I really don't understand where Canonical gets in here. If qreal is float on armhf and key software fails in that configuration then canonical have to fix it (ubuntu are usually either very close to or ahead of debian on key software) Afaict neither armel or sh4 has anything like the level of corporate support that armhf gets from canonical. Ah, you mean that armhf hardware has more support from the Ubuntu side. Anyway, we need to make this decision within Debian. I also don't understand what you mean with ports that stick with qreal. qreal is a typedef which type is defined at compile time. Did you meant float? Sorry I meant ports that stick with defining qreal as float. I see, in this case only those ports will have to deal with that (as it has been with Qt4) I have not participated in any way in upstream's decision nor I have the power to overcome them. Anyway, we are giving the choice of a compile-time parameter to better suit our needs on purpose. The problem is this is going to have a massive affect on ABI which implies: 1: changing the descision later would mean a soname change The reason why I took the time to create this thread is because this is the time to take that decision, and we Qt maintainers will not change it later because that would mean a soname change. 2: if debian make a different descision from other distros we will be binary incompatible. Sune just made me rmember LSB. Yes, indeed, we need to try and coordinate with other distros. How this is normally done? Kinds regards, Lisandro. -- Un viejo proverbio de El.Machi dice que la memoria es como las papas fritas... ¡nunca sobran! Lisandro Damián Nicanor Pérez Meyer http://perezmeyer.com.ar/ http://perezmeyer.blogspot.com/ signature.asc Description: This is a digitally signed message part.
Re: Potential issues for most ports (Was: Re: Bits from the Release Team (Jessie freeze info))
On 03/11/13 10:54, Niels Thykier wrote: Come to think of it; maybe we should have a BTS page for each of the ports (e.g. a pseudo package in the BTS). We've had this on kfreebsd, due it to having been a release goal: http://udd.debian.org/bugs.cgi?release=jessie_or_sidmerged=ignfnewerval=7kfreebsd=1sortby=severitysorto=desccseverity=1ctags=1 It uses usertags, but someone has to set those. Porters usually set them on bugs they file; but quite often FTBFS on kfreebsd bugs are filed without being tagged or Cc'd to our list, so someone has to periodically look for and tag things. Regards, -- Steven Chamberlain ste...@pyro.eu.org -- To UNSUBSCRIBE, email to debian-amd64-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/527665af.2040...@pyro.eu.org
Re: Qt5 switching qreal from float to double on arm*
On Saturday 02 November 2013 15:29:05 Lisandro Damián Nicanor Pérez Meyer wrote: [snip] We have the option to keep some archs in float by passing a compilation parameter. I've done so for armel and sh4, so only armhf will switch to double. Just for the record, I din't considered the switch for armel and sh4 because I think that may slow down those archs a lot, but please understand that I do not have a solid background for stating this, so feel free to correct me here. -- Lisandro Damián Nicanor Pérez Meyer http://perezmeyer.com.ar/ http://perezmeyer.blogspot.com/ signature.asc Description: This is a digitally signed message part.
Re: Qt5 switching qreal from float to double on arm*
On Sat, 02 Nov 2013 15:29:05 -0300 Lisandro Damián Nicanor Pérez Meyer perezme...@gmail.com wrote: Hi! Starting from Qt 5.2.0 (most probably from rc1 and definitely not from beta1 currently in experimental) Qt5 will switch qreal from float to double on arm*. We have the option to keep some archs in float by passing a compilation parameter. I've done so for armel and sh4, so only armhf will switch to double. Of course we are still on time to discuss this, and this is the reason of this mail. What do you think WRT the above changes? FWIW, I was a bit sceptical about switching qreal to double. True this would minimise the patches some packages would need on armhf, but OTOH, I don't know what would happen to packages that use both GL graphics and Qt at the same time. All armhf platforms support only OpenGLES and not full OpenGL stack which supports *only* 32-bit floats. However Lissandro just told me on IRC that GL-stuff on Qt5 switched to float for exactly that reason). So apart from speed I don't see a reason for not going that route. If anything, FPU in recent armv7-a systems has become increasingly better so this will be better in a couple of years (it will still suck on a Cortex-A8, but will be less apparent on a Cortex-A15 or better). FTR, I don't think many apps would mind that much. Most apps that would actually care for speed/accuracy would use float/double directly and not qreal, for most it would save us the burden of patching (eg. scribus, qgis). So unless, we find some particular strong cases for *not* switching to double, I'd vote in favour of that. Regards Konstantinos pgpqL57sYACJt.pgp Description: PGP signature
Re: Qt5 switching qreal from float to double on arm*
On Monday 04 November 2013 17:57:35 Pau Garcia i Quiles wrote: Hello, Simple question: what is the reason for the change? This is all I know: https://codereview.qt-project.org/#change,67001 Also, I seem to remember Thiago discussing about this on qt-interest but I don't have time to search just now. Apart from the links Peter sent in his mail, I haven't seen the discussion at all (I would really love to be more involved upstream, but my needs for a paycheck don't allow it ;) ) -- Lisandro Damián Nicanor Pérez Meyer http://perezmeyer.com.ar/ http://perezmeyer.blogspot.com/ signature.asc Description: This is a digitally signed message part.
Re: Potential issues for most ports (Was: Re: Bits from the Release Team (Jessie freeze info))
On 2013-11-03 16:03, Steven Chamberlain wrote: On 03/11/13 10:54, Niels Thykier wrote: Come to think of it; maybe we should have a BTS page for each of the ports (e.g. a pseudo package in the BTS). We've had this on kfreebsd, due it to having been a release goal: http://udd.debian.org/bugs.cgi?release=jessie_or_sidmerged=ignfnewerval=7kfreebsd=1sortby=severitysorto=desccseverity=1ctags=1 Actually, I meant a real BTS page (e.g. like [1]) rather than just a list of tagged bugs. The list of tagged bugs definitely have it uses, but it does not give me an overview of which bugs should be fixed by the maintainer of the given package and which the porters should fix. It uses usertags, but someone has to set those. Porters usually set them on bugs they file; but quite often FTBFS on kfreebsd bugs are filed without being tagged or Cc'd to our list, so someone has to periodically look for and tag things. Regards, In this regard; I am guilty of filing some those bugs without tagging them. Honestly, adding the tags get a bit in the way right now. If a package FTBFS on 4 architectures, I have to dig up 3-4 different usertags (with different user) and associate it with the bug. Do we have a tool you can give a source package, a version plus a list of architectures and it will generate a bug with the right tags? I think that would help a lot for me. ~Niels [1] http://bugs.debian.org/release.debian.org -- To UNSUBSCRIBE, email to debian-amd64-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/52789fdb.2000...@thykier.net
Re: Potential issues for most ports (Was: Re: Bits from the Release Team (Jessie freeze info))
On 2013-11-03 23:04, Steve Langasek wrote: On Sun, Nov 03, 2013 at 11:54:34AM +0100, Niels Thykier wrote: [...] I suppose a sponsor-only DD could be sufficient, provided that the sponsor knows the porters well enough to be willing to sign off on e.g. access to porter boxes. I guess the sponsor would also need to dedicate time to mentor (new?) porters on workflows and on quicks like when is a FTBFS RC and when it isn't etc. Why would the sponsor need to be involved in getting the porters access to porter boxes? Porter boxes exist so that DDs *not* involved in a port have access to a machine of the architecture and can keep their packages working. I've never heard of a porter who didn't have access to their own box for porting work. I will not rule out that it was a poor choice of example on my part for ia64 (and maybe powerpc), which is(/are) the concrete port(s) we would be talking in this case. That said, it is my understanding that one does not simply own an s390(x)[1]. Nor would I be concerned to have arm porters that worked on all 3 arm ports while possessing hardware only for a (non-empty) subset of those architectures. ~Niels [1] I certainly wouldn't have space for something like this: http://en.wikipedia.org/wiki/File:Z800_2066_JKU.jpeg (and much less the money. Yeah I know that is technically not an s390, but as I understand it, an s390 should be around that size) -- To UNSUBSCRIBE, email to debian-amd64-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/5278a3e1.30...@thykier.net
Potential issues for most ports (Was: Re: Bits from the Release Team (Jessie freeze info))
On 2013-10-29 17:48, Ian Jackson wrote: Niels Thykier writes (Re: Bits from the Release Team (Jessie freeze info)): [...] As mentioned we are debating whether the 5 DDs requirement still makes sense. Would you say that we should abolish the requirement for DD porters completely? I.e. Even if there are no (soon to be) DDs, we should consider the porter requirements fulfilled as long as they are enough active porters behind the port[0]? I don't have a good feel for the answer to that question. It's just that if it is the case that a problem with ports is the lack of specifically DDs, rather than porter effort in general, then sponsorship is an obvious way to solve that problem. If you feel that that's not really the main problem then a criterion which counts porters of any status would be better. I suppose a sponsor-only DD could be sufficient, provided that the sponsor knows the porters well enough to be willing to sign off on e.g. access to porter boxes. I guess the sponsor would also need to dedicate time to mentor (new?) porters on workflows and on quicks like when is a FTBFS RC and when it isn't etc. (Mind you, I have my doubts about a process which counts people promising to do work - it sets up some rather unfortunate incentives. I guess it's easier to judge and more prospective than a process which attempts to gauge whether the work has been done well enough.) [...] Thanks, Ian. Ah, you are not the first to question this process. Obviously, we intend to keep people up on their promise by actively maintaining their port. Sadly, we do not have a clear definition of actively maintained ports and I doubt we will have it any time soon either. But porters can start by working on the concerns from DSA (if they haven't already done so). Ports having gcc-4.6 as default compiler might also consider improving in that area[1]. Then there are more concrete things like ruby's test suite seg. faulting on ia64 (#593141), ld seg. faulting with --as-needed on ia64 (#718047[2]), a lot of ruby packages being stuck on kfreebsd-any due to ruby2.0 FTBFS (#726095[3]). Personally, I would also expect that key-packages work on all ports (on which they are built) in general[4]. All of the (non-mild) DSA concerns are already something we will officially hold against the ports. Most of the other issues listed above are not official concerns. However, I would not be surprised if most of them became official issues eventually. Until we have a clear definition of actively maintained ports, I would recommend porters to err on the side of being verbose over being silent. As an example, lack of visible reply to mails like [5] makes it seem like nobody is home. Mind you, I am not saying porters have the responsibility to fix every problem forwarded to their port list. I am also aware that sometimes issues/mail disappear in the depths of people inbox - heck it happens to me as well. Come to think of it; maybe we should have a BTS page for each of the ports (e.g. a pseudo package in the BTS). That way it would at least be easier for all people to find outstanding issues for the port[6]. It would also give us the possiblity to trivial declare a problem RC (or not) for ports. (Plus, then I won't have to update some random file on release.d.o for every new issue :P) Anyhow, I hope to be able to give a more official statement in the near future. ~Niels [1] Nothing official yet, but gcc-4.6 (and earlier) /might/ not be acceptable as a default for Jessie. [2] Apparently it is controversial whether that bug should be RC, but it definitely looks like that kind of thing that will cause issues for ia64 later. [3] That one got a patch, but it might be worth it to put some pressure on the maintainer or even doing a NMU. [4] A rule of thumb could be something like your port should probably not be listed here in the long run: http://udd.debian.org/bugs.cgi?release=jessie_and_sidmerged=ignkeypackages=onlyfnewerval=7flastmodval=7rc=1sortby=idsorto=asc [5] https://lists.debian.org/debian-mips/2013/08/msg5.html Btw, this is not intended to single out mips. [6] I know that people have been usertags for issues that affect the port, but it is not clear to me that all those usertags bugged is something we expect porters to fix. Rather it seems more like porters tagging the FTBFS bugs they file. -- To UNSUBSCRIBE, email to debian-amd64-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/52762b6a.5060...@thykier.net
Re: Potential issues for most ports (Was: Re: Bits from the Release Team (Jessie freeze info))
Niels Thykier dixit: Then there are more concrete things like ruby's test suite seg. faulting on ia64 (#593141), ld seg. faulting with --as-needed on ia64 And only statically linked klibc-compiled executables work on IA64, not dynamically linked ones. I’ve looked into it, but Itanic is so massively foreign I didn’t manage to find out anything except that the problem appears to happen before main. Until we have a clear definition of actively maintained ports, I would recommend porters to err on the side of being verbose over being silent. I’ve held off on the m68k side because I think the role call was only for architectures in the main archive, right? [1] Nothing official yet, but gcc-4.6 (and earlier) /might/ not be acceptable as a default for Jessie. Didn't Doko say he’d want 4.8? We (on the m68k side) are putting effort into that one, since 4.7 appears to only be used by eglibc right now. And 4.6 for GNAT, but gnat-4.8 is new, and the ICE may be fixed as there’s active upstream on the GCC/m68k side. bye, //mirabilos -- diogenese Beware of ritual lest you forget the meaning behind it. igli yeah but it means if you really care about something, don't ritualise it, or you will lose it. don't fetishise it, don't obsess. or you'll forget why you love it in the first place. -- To UNSUBSCRIBE, email to debian-amd64-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/pine.bsm.4.64l.1311031444380.31...@herc.mirbsd.org
Re: Potential issues for most ports
On 2013-11-03 15:49, Thorsten Glaser wrote: Niels Thykier dixit: [...] Until we have a clear definition of actively maintained ports, I would recommend porters to err on the side of being verbose over being silent. I’ve held off on the m68k side because I think the role call was only for architectures in the main archive, right? Yes, we are only talking about architectures in the main architecture. [1] Nothing official yet, but gcc-4.6 (and earlier) /might/ not be acceptable as a default for Jessie. Didn't Doko say he’d want 4.8? We (on the m68k side) are putting effort into that one, since 4.7 appears to only be used by eglibc right now. And 4.6 for GNAT, but gnat-4.8 is new, and the ICE may be fixed as there’s active upstream on the GCC/m68k side. bye, //mirabilos I am not entirely up to speed on what he wants; I am still waiting for him to get back to me (see [1]). ~Niels [1] https://lists.debian.org/debian-release/2013/10/msg00710.html -- To UNSUBSCRIBE, email to debian-amd64-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/527671af.7050...@thykier.net
Re: Potential issues for most ports
On 2013-11-03 16:54, Niels Thykier wrote: On 2013-11-03 15:49, Thorsten Glaser wrote: Niels Thykier dixit: [...] Until we have a clear definition of actively maintained ports, I would recommend porters to err on the side of being verbose over being silent. I’ve held off on the m68k side because I think the role call was only for architectures in the main archive, right? Yes, we are only talking about architectures in the main architecture. s/main arcihtecture/main archive/; ~Niels -- To UNSUBSCRIBE, email to debian-amd64-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/527674bd.2070...@thykier.net
