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
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
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
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
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
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
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++
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?
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
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
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
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
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
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
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
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
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
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, …
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
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
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
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
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
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
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
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
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
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.
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
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
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
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
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
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
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
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
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?
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
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
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
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:
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
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
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
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
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
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,
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,
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.,
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
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:
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
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
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])
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
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
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
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
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
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
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
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
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
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
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
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
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
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. :)
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
PUBLI NEWS NATURVALENCIA
Wenn nicht, diese Informationen, folgen
Sie bitte
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
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
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
# 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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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:
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
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
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
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:
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
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
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
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
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
701 - 800 of 22900 matches
Mail list logo
