Re: Bug#1057050 closed by Debian FTP Masters (reply to Patrick Franz ) (Bug#1057050: fixed in qt6-multimedia 6.6.1-1)
Control: reopen -1 Hi, looks like this didn't work: > https://buildd.debian.org/status/fetch.php?pkg=qt6-multimedia&arch=powerpc&ver=6.4.2-11&stamp=1705003199&raw=0 Reopening the bug therefore. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: unbreaking LibreOffices tests on at least release architectures
Hello! On Sun, 2023-06-18 at 09:31 +0200, Rene Engelhard wrote: > Also note I am not talking about the debian-ports architectures. Those I > forgot and I have no problems making them stay into "testsuite ran but > results ignored" set. Why did you send this mail exclusively to debian-ports then? > Right now, the only architectures where the test actually work (ignoring > the occassional breakage on arm64 which is fixed upstream since they do > aarch64 flatpak builds) is amd64 and arm64. > (...) > I don't really like sweeping it under the carpet again and would > actually pursue the "getting those architectures removed from unstable" > way pointed out and (implicitely) approved/suggested by the release team... You want Debian to drop support for all architectures except amd64 and arm64 because a single package doesn't pass its testsuite on the other architectures? Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#955338: sbcl: Please backport patch to fix build on kfreebsd-*
Source: sbcl Severity: normal Tags: patch User: debian-bsd@lists.debian.org Usertags: kfreebsd-amd64 Hi! sbcl fails to build from source on kfreebsd-amd64 [1] the same way it did on powerpc, so I sent a patch upstream which was merged to fix the issue the same way as on powerpc [2]. Can you include the attached patch for the next upload to fix the build on kfreebsd-*? Thanks, Adrian > [1] > https://buildd.debian.org/status/fetch.php?pkg=sbcl&arch=kfreebsd-amd64&ver=2%3A2.0.2-2&stamp=1584178866&raw=0 > [2] > https://github.com/sbcl/sbcl/commit/d85d2f8c39e7fc6feca3ebf6f494c961dc5226d8 -- .''`. 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 >From d85d2f8c39e7fc6feca3ebf6f494c961dc5226d8 Mon Sep 17 00:00:00 2001 From: John Paul Adrian Glaubitz Date: Mon, 30 Mar 2020 01:04:48 +0200 Subject: [PATCH] kfreebsd: Add -no-as-needed to OS_LIBS --- src/runtime/Config.x86-64-gnu-kfreebsd | 2 +- src/runtime/Config.x86-gnu-kfreebsd| 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/src/runtime/Config.x86-64-gnu-kfreebsd b/src/runtime/Config.x86-64-gnu-kfreebsd index 89975c48f..6fd4cdd05 100644 --- a/src/runtime/Config.x86-64-gnu-kfreebsd +++ b/src/runtime/Config.x86-64-gnu-kfreebsd @@ -15,7 +15,7 @@ include Config.x86-64-bsd # worked fine for most things, but LOAD-FOREIGN & friends require # dlopen() etc., which in turn depend on dynamic linking of the # runtime. -OS_LIBS += -lutil -ldl +OS_LIBS += -lutil -ldl -Wl,-no-as-needed # use libthr (1:1 threading). libpthread (m:n threading) does not work. ifdef LISP_FEATURE_SB_THREAD diff --git a/src/runtime/Config.x86-gnu-kfreebsd b/src/runtime/Config.x86-gnu-kfreebsd index 385209023..e49dde4a6 100644 --- a/src/runtime/Config.x86-gnu-kfreebsd +++ b/src/runtime/Config.x86-gnu-kfreebsd @@ -17,7 +17,7 @@ include Config.x86-bsd # runtime. LINKFLAGS += -dynamic -Wl,--export-dynamic -m32 -OS_LIBS += -lutil -ldl +OS_LIBS += -lutil -ldl -Wl,-no-as-needed # use libthr (1:1 threading). libpthread (m:n threading) does not work. ifdef LISP_FEATURE_SB_THREAD -- 2.26.0
Re: Hurd-i386 and kfreebsd-{i386,amd64} removal
Could you PLEASE stop posting to debian-ports@? You are sending these mails to
every Debian Ports architecture mailing list.
I already asked for the third time now.
Thank You,
Adrian
> On May 26, 2019, at 5:34 AM, wrote:
>
> Sorry if this is off-topic, but I can't help asking if that "15381 March
> 1977" was on purpose or just from some wonky email client: 15380 days after
> March 1st 1977 happens to be April 10th 2019, so...
>
> --
> Pengcheng Xu
> https://jsteward.moe/
>
>
>> -Original Message-
>> From: Aurelien Jarno
>> Sent: Saturday, May 25, 2019 4:56 PM
>> To: debian-h...@lists.debian.org; debian-bsd@lists.debian.org; debian-
>> de...@lists.debian.org; debian-po...@lists.debian.org; ftpmaster@ports-
>> master.debian.org
>> Subject: Re: Hurd-i386 and kfreebsd-{i386,amd64} removal
>>
>> Hi,
>>
>>> On 2019-04-24 12:34, Joerg Jaspert wrote:
>>> On 15381 March 1977, Aurelien Jarno wrote:
> ^^^ HERE
>>>
>> It would be nice to have a bit more than 2 weeks to do all of that.
> Ok. How much? Is 6 or 8 weeks better? I don't think, given how
> long this is on the table already, it doesn't make much difference if its
> 2
>> or 8.
> Just something thats clear defined and not some random, non-clear
> "sometime in the future" point.
The hurd-i386 architecture has been moved to to debian-ports yesterday.
I hope it shows the willingness to do that. Please give us at least
4 more weeks to do the remaining kfreebsd-*. That will provide some
margin to account for the non-infinite free time to work on that
(especially in the freeze period) and possibly to get more disk
space for the debian-ports machine.
>>>
>>> Thats ok, end of May is a nice point to take.
>>>
>>> Thanks for the work and the timeframe for the rest!
>>
>> kfreebsd-amd64 and kfreebsd-i386 have now been moved to debian-ports.
>> As
>> hurd-i386 has been moved earlier, it means that all the 3 architectures have
>> now been moved.
>>
>> Aurelien
>>
>> --
>> Aurelien Jarno GPG: 4096R/1DDD8C9B
>> aurel...@aurel32.net http://www.aurel32.net
Re: Hurd-i386 and kfreebsd-{i386,amd64} removal
Hello! Just as a heads-up: Sending mail to debian-ports@l.d.o ends up sending the mail to debian-alpha@, debian-hppa@, debian-ia64@, ... simultaneously, so it would be better to avoid using this address in the discussion. Thanks, 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
Re: Arch qualification for buster: call for DSA, Security, toolchain concerns
Hello! On 12/9/18 3:18 PM, Matthias Klose wrote: > To me it looks sometimes that Debian is used for testing by upstream, and for > that the mips architectures don't need to be release architectures. A note on this: If you decide to move MIPS to Debian Ports, you will make the port unusable to most users as Debian Ports has a rather rudimentary FTP archive setup which has some annoying side effects. There is no support for a testing release, there is no support for cruft and the FTP maintainers will eventually remove any MIPS-only packages from the Debian archive which don't build on other architectures which usually affects packages like boot loaders meaning that it will no longer be easily possible to build the debian-installer package and consequently build installation images. The 32-bit PowerPC port lost quite a number of users because of this change. Not because the port was not healthy but because people want to be able to install a stable release. Debian unfortunately doesn't have really good support for Tier II architectures, it's either release or something based on unstable that requires extra elbow grease from both users and maintainers. Please also keep in mind that removing MIPS from the list of release architectures would mean one less open platform on which Debian is supported. Neither anything based on ARM, x86 or IBM Z provides a true open platform due to the proprietary nature of these architectures. There are some efforts in this regard on IBM POWER, but the hardware is still rather expensive, unfortunately. I do hope that RISC-V will catch up in the future though. I also think that the broad architecture support is one of the selling points of Debian and if we were to limit Debian's architecture support to just ARM, x86, POWER and IBM Z, I fear that Debian would more and more be turned into a mere development project for Ubuntu and other derivatives rather than being an operating system of its own. Thanks, 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
Re: Re-evaluating architecture inclusion in unstable/experimental
Hi Philipp! On 10/3/18 4:29 PM, Philipp Kern wrote: > Please excuse my ignorance, but which architecture do we still have with > 2 GiB address space? The main point of removing s390 was that this was > unsustainable. The 32-bit MIPS architectures have this limitation which causes various build issues up to the point that maintainers have to reduce optimization levels for the C/C++ compiler to be able to build a package. Another issue is that the Rust compiler, despite being fully supported on 32-bit MIPS, cannot be built natively there because the build process runs out of memory at some point. >> I have seen IBM people on multiple occasions in various upstream >> projects trying to remove code for older POWER targets because >> they insisted anything below POWER8 is not supported anymore. In >> some cases like Golang with success [1]. > > Yeah, IBM behavior has been incredibly frustrating here on the System z > side, too. Essentially they end up actively removing support for > anything they don't support anymore. Somewhat relieves me to hear that I'm not the only one running into this problem. I find it frustrating though since it leaves a bad impression on what attitude IBM has towards open source and the community. > To some degree I understand this behavior: It's a real relieve to not > need to support something old and crufty when you're the engineer on the > other side having to do that. Even when such support is contributed, > someone needs to keep it working and they won't keep old hardware around > for that. Sure, I understand that. But in the case of Golang, the necessary extra code paths are really manageable. In fact, have my own tree of Golang where I reverted the changes which dropped POWER5 support and I keep rebasing this tree from time to time and it still works fine. It does work without problems on the x86 side with the kernel and the toolchain still supporting rather old hardware. POWER5 isn't that old. > But it has very awkward implications on the people that still have that > hardware for one reason or another and don't actually rely on a support > contract. My main argument is that if there are still a reasonable amount of users and there are still enough people to help maintain a port, it should not removed just because it's old. In the end, software is written to be useful to users and not for the sake of the people writing it. > For s390x I can say that the port was driven without any commercial > interest on both Aurelien's and my side The question is though: Is there quantifiable amount of users that is running Debian on such big iron instead of one of the Linux enterprise distributions on the market? If the argument is about maintenance burden, then does it justify to support Debian on s390x when the number of users is small? And, if yes, why does that not apply to ppc64, for example? (I would mention sparc64 here as well, but there is actually a valid blocker which is the lack of supply of new hardware for DSA). Thanks for the insight! 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
Re: Re-evaluating architecture inclusion in unstable/experimental
On 9/29/18 8:48 AM, Ben Hutchings wrote: > On Fri, 2018-09-28 at 14:16 +0200, John Paul Adrian Glaubitz wrote: > [...] >> Furthermore, several of the ports are in very healthy condition and >> even surpass some release architectures. The powerpc and ppc64 ports, >> for example, build more packages than any of the mips* ports. > > I would be very happy to never have to wait for MIPS builds again. I don't have a problem with waiting for slow machines. I just think this shows that the decisions what becomes a release architecture and what doesn't isn't purely meritocratic. >> As for the kernel maintenance, except for Alpha, all the ports have >> at least one kernel maintainer: >> >> * hppa: actively maintained by two people who also maintain the toolchain > > But the hardware is EOL since 2008. Well, the hardware is usually build like tanks and if people keep using it and others keep maintaining it, why throw something out when it's still working? SAP is still maintaining and supporting JDK on PA-RISC and IA64 for paying customers, FWIW. >> * ia64: maintained by one paid developer at Intel > > To the extent of 2 whole commits this year! I'm pretty sure this is > not actually his job any more. Jason Duerstock talked to him and he said, he's still doing this as a job at Intel because basically no one told him to stop doing it. >> * m68k: maintained by multiple independent kernel maintainers, at least >> five people involved upstream; port is also getting new drivers > > But the available hardware is either too slow to be useful, or only > available through crowdfunding (maybe, eventually). Yes, this is being worked on. There are FPGA-based implementations which allow to boost Amiga and Atari hardware to considerably higher speeds. It's not done on a large commercial scale, so things take longer to develop. But people are working on it and bugs get fixed, code maintained and drivers added. >> * powerpc/ppc64: maintained mostly by IBM people > > IBM looks after 64-bit configurations, so ppc64 is covered but not > powerpc. Well, I have had people from IBM fix 32-bit PowerPC code. There is naturally more involvement behind the 64-bit stuff because that's where the commercial interests are. >> * sh4: maintained by two kernel maintainers > > That may be, but the Debian port isn't stable enough to *build* a > kernel: https://buildd.debian.org/status/logs.php?pkg=linux&arch=sh4 That's a compiler bug, I know. >> * sparc64: used to be maintained by a team at Oracle but Oracle recently >> changed their mind about Linux on SPARC; now it's back to >> David Miller and some additional volunteers > > Oracle laid off their SPARC team. Fujitsu has another SPARC processor > in development, but only for supercomputers (and they seem to be > switching to Aarch64 later). So we can expect this architecture to > slowly fade away now. What Oracle is really doing and planning isn't really clear. I have talked to multiple people at Oracle directly and the consensus is that there isn't a consensus what is going to happen next. But again, this just supports my point that the decisions which ports become release architectures is mostly driven by commercial interests and not whether there are users in the community. Or is there actually a large community of POWER8 and z-Series Debian users? >> * x32: maintained by the people who maintain the x86 port of the kernel > > H. Peter Anvin did the original port in 2012, but so far as I can see > none of the x86 maintainers have done any development on it since then. > And yes, development work has been needed: > > - x32 has 64-bit time_t and that never worked quite right. This may > have finally been fixed this year by Arnd Bergmann's work, but I'm > not sure. > - syscall restart was broken until 2015 when someone actually tested > it. > - There have been several regressions specific to x32, some of which > stuck around for a year or so before someone and fixed them. > > [...] > > So, by all means have fun working on these ports, but aside from ppc64 > I don't see any prospect of them meeting release qualifications. I think the problem that I have is that the release qualifications are not practical in the sense that they don't necessarily meet our users expectations. As I said, I think a tier-based system would be more practical as it would allow ports to be degraded more gracefully instead of just kicking them out like it was done with 32-Bit PowerPC. I don't have a proper concept yet, but I think the OBS approach is more versatile, for example. 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
Re: Re-evaluating architecture inclusion in unstable/experimental
On 9/28/18 11:26 PM, Adam D. Barratt wrote: > On Fri, 2018-09-28 at 14:16 +0200, John Paul Adrian Glaubitz wrote: >> So, it's not always a purely technical decision whether a port >> remains a release architecture. It's also often highly political and >> somehow also influenced by commercial entities. > > Please don't make implications like that unless you can back them up. Well, I cannot prove it. But when I see that we have ports as release architectures with hardware where atomics in hardware don't even work correctly and the virtual address space is limited to 2 GiB per process while on the other hand perfectly healthy and maintained ports like powerpc and ppc64 which have actually a measurable userbase and interest in the community are axed or barred from being a release architecture, then I have my doubts that those decisions aren't also driven by commercial interests or politics. I have seen IBM people on multiple occasions in various upstream projects trying to remove code for older POWER targets because they insisted anything below POWER8 is not supported anymore. In some cases like Golang with success [1]. > Adam > (involved to greater or lesser extent in every decision as to whether > an architecture should be added to or removed from testing over the > past almost decade, with no commercial interest involved in any way) I understand that. But if stuff that gets removed despite people using it and despite others maintaining it, I am having my doubts. And it has happened more than once where I had to explain users why there aren't any stable releases anymore they can install on their PowerPC-based machines. I really do not mean to accuse anyone of malevolence, I am merely speaking from my personal observations that sometimes such decisions do not necessarily meet the expectations of our users and that there might be a path for improvement, e.g in the form of support tiers like they exist in NetBSD. Thanks, Adrian > [1] https://github.com/golang/go/issues/19074 -- .''`. 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
Re: Re-evaluating architecture inclusion in unstable/experimental
Hello! I just saw this mail this morning by accident while browsing the archives, I am not subscribed to debian-devel. > The ftpmaster team would like to clarify which Debian ports should and/or would like to continue to be part of Debian unstable and experimental. I'm not sure what context you are referring to? Are you talking about architectures that are present in the main archive or do you also include Debian Ports which has its own FTP server and buildds maintained outside DSA? > As outlined on the Debian Archive Criteria page[0], the key points to consider are whether the architecture has been part of a stable release, whether it is *likely* to be part of a stable release, as well as whether it currently has a sensible number of active maintainers. All ports in Debian Ports have at least one maintainer otherwise it wouldn't be possible to keep the pace with unstable. Furthermore, several of the ports are in very healthy condition and even surpass some release architectures. The powerpc and ppc64 ports, for example, build more packages than any of the mips* ports. As for the kernel maintenance, except for Alpha, all the ports have at least one kernel maintainer: * hppa: actively maintained by two people who also maintain the toolchain * ia64: maintained by one paid developer at Intel * m68k: maintained by multiple independent kernel maintainers, at least five people involved upstream; port is also getting new drivers * powerpc/ppc64: maintained mostly by IBM people * sh4: maintained by two kernel maintainers * sparc64: used to be maintained by a team at Oracle but Oracle recently changed their mind about Linux on SPARC; now it's back to David Miller and some additional volunteers * x32: maintained by the people who maintain the x86 port of the kernel > Whilst you may be happy to continue the work of maintaining the port regardless, don't forget that excess or otherwise unnecessary architectures involve a shared maintenance burden as well as incurring non-trivial requirements on mirror/Debian resources. Debian Ports has its own mirrors. Besides, I think one of the main selling points of Debian is its portability. If we take away this feature, we become less attractive. If the maintenance burden is too high, it might be an idea to switch to a more flexible and powerful infrastructure like SUSE's OBS which makes handling of new ports much easier. It's very easy to set up your own OBS, so people within SUSE do that to maintain their own ports, for example. > The statistics and graphs available on the debian-ports page[1] may provide some objective statistics or reflection on the actual suitability of your architecture's continued inclusion. Jepp. And as you can see, several ports that are thought to be dead long time ago are healthier than some of the official Debian release architectures simply because there are huge communities behind it. The m68k port has a very strong and enthusiastic community which is why the port has already survived multiple other architectures in the kernel like TileGX and similar. There are people building new m68k hardware, writing new drivers and there is even an ongoing effort to create an m68k backend for LLVM so that we can eventually even start building Rust packages (I have already added partial target support for m68k in a local Rust branch). So, it's not always a purely technical decision whether a port remains a release architecture. It's also often highly political and somehow also influenced by commercial entities. Although I think Debian, being a community distribution, should be more oriented towards its community and not towards commercial interests. > So, in the first instance, would you like to continue being part of unstable/experimental? All Debian Ports architectures [1] should remain part of unstable and experimental and are very actively maintained by the Debian Ports team. You can find us in #debian-ports on OFTC. FWIW, we have our own instance of the transition tracker: > https://ben.jrtc27.com/ Thanks, Adrian > [1] https://buildd.debian.org/stats/graph-ports-big.png -- .''`. 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
New Debian Ports installation images delayed
Hi! I had promised to build new installation images for Debian Ports last week. This has been delayed because of a regression of debian-installer on powerpc and ppc64 due to a change in the kernel packaging. A fix has now been submitted and the kernel packages will soon be rebuilt on powerpc and ppc64 once the FTP servers are in sync again. Once the kernel packages have been rebuilt, I can try building debian-installer on powerpc and ppc64 again and if that works, I can build new installation images. 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
Re: armel/armhf arch qualification for buster: call for DSA, Security, toolchain concernsj
Hi Roger! On 07/23/2018 10:42 AM, Roger Shimizu wrote: > I talked to a few people about keeping armel in buster, during 1st and > 2nd day in debcamp. > Seems the blocker is just the buildd server hardware, and memory size it has. According to my colleague Alex Graf at SUSE, you can definitely build ARMv7 on arm64 using chroots. The only problem with chroots is that "uname -a" shows "armv8" which some userspace applications are stumbling over. openSUSE/SLE builds armv7 packages in OBS/IBS using a fully emulated system using KVM. As for the hardware, you should watch out for hardware with ARM Cortex Cores. Alternatively, X-Gene 1. ThunderX, ThunderX2 and Centriq are definitely not supported. 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
Re: Debian/MIPSeb: proposal to drop mipseb port?
Hi! You should ask in a more public forum rather than on Debian mailing lists if you want to know about potential users. Adrian > On Jul 7, 2018, at 8:31 AM, YunQiang Su wrote: > > Hi, folks, > due to lack of enough man power and build machines for 3 mips* port at > the same time, I think that now it is time for us to have a talk about > dropping mips32eb support now. > > mips32eb, named mips, in our namespace, is used by few people now, at > least compare with mipsel/mips64el. > > The reason we keep it till now is > 1) some people are still using it. > 2) it is the only port 32bit and EB now. > > In fact I don't know anybody is using Debian's mips32eb port. > If you are using it, please tell us.
Re: Arch qualification for buster: call for DSA, Security, toolchain concernsj
On 06/29/2018 10:41 AM, Luke Kenneth Casson Leighton wrote: > On Fri, Jun 29, 2018 at 8:16 AM, Uwe Kleine-König > wrote: > >>> In short, the hardware (development boards) we're currently using to >>> build armel and armhf packages aren't up to our standards, and we >>> really, really want them to go away when stretch goes EOL (expected in >>> 2020). We urge arm porters to find a way to build armhf packages in >>> VMs or chroots on server-class arm64 hardware. > > from what i gather the rule is that the packages have to be built > native. is that a correct understanding or has the policy changed? Native in the sense that the CPU itself is not emulated which is the case when building arm32 packages on arm64. We're also building i386 packages on amd64 and we used to build powerpc packages on ppc64 (and we will continue to do that once the move of powerpc to ports has been completed). I think that building on arm64 after fixing the bug in question is the way to move forward. I'm surprised the bug itself hasn't been fixed yet, doesn't speak for ARM. 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
Archiving the attic folders from d-i for ports
(Re-send because I forgot debian-ports-devel@alioth is dead, please reply to debian-boot@) Hi! I was pointed at Steve's mail yesterday mentioning that he moved the non-attic repositories of debian-installer to salsa [1]. Since there are still some repositories that we need for debian-ports in the attic, I was wondering whether we should take care of the attic stuff and move it over to salsa or github. FWIW, we are in the progress of moving the sparc* and ppc* ports which aren't on GRUB yet fully over. In fact, GRUB works fine on all SPARC boxes we have tested so far, so at least silo-installer won't be needed anymore in the future. Still, I think we should archive everything. Adrian > [1] https://lists.debian.org/debian-boot/2018/04/msg00253.html -- .''`. 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
Re: Bug#895193: transition: openmpi
On 04/11/2018 10:53 AM, Alastair McKinstry wrote: As of 3.0.1, openmpi now works on Big-Endian powerpc (which was to be a problem; it had been dropped upstream because of an unknown bug, now fixed). Oh, really, they fixed that? I already had given up hopes and therefore ignored the thread on github out of frustration. The other non-release archs were failing due to missing dependencies: in particular java support (not used by any package in stable/testing) and pmix (new; not used in testing/stable; pmix enables scaling to ~100,000+ nodes, which is unlikely to be needed). I am working on fixing the remaining OpenJDK issues. I'm an upstream committer in the OpenJDK project, so I can commit all changes myself. So, the expected changes to mpi-defaults will no longer be needed. Yay, thanks so much for this! 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
Rust architecture status
ult, using libc::c_long doesn't work. We have to use "i64" on x32 instead. Necessary work: Fix the crash above. Also, get D43630 (https://reviews.llvm.org/D43630) merged in LLVM upstream. Fix the remaining 64-bit time issues in crates like "filetime" and "time". 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
Updated installer images
Hi! I have generated an updated set of debian-installer images for Debian Ports which also now includes alpha [1]. I have fixed the installation issues on hppa and sparc64, in both cases the bootloader installer was missing. ppc64 has still some issues with the partition manager, but I'm working on fixing that. Please test and report back on the individual architecture mailing lists, i.e. please don't post to debian-ports@l.d.o as this reaches the mailing lists of all ports. Adrian [1] https://cdimage.debian.org/cdimage/ports/ -- .''`. 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
New download location for Debian Ports ISOs
Hi! I am cross-posting this to debian-ports@l.d.o because it affects all Debian Ports architectures. As of today, we will be using Debian's official cdimage mirror to host the installation images for Debian Ports, the images can be found in [1]. I have uploaded images for hppa, m68k, ppc64 and sparc64. I am working on uploading more images. Images for alpha are currently missing due to issues with the Linux kernel packages which fails to build on alpha at the moment. Please test the images as thoroughly as you can and report your results to the appropriate architecture-specific mailing lists. Please do not post to this mailing list, debian-ports@l.d.o, as this will cross-post your mail to ALL Debian Ports architectures mailing lists. A huge thanks to Steve McIntyre and the Debian Sysadmins for providing us access to the official cdimage mirror. Thanks, Adrian > [1] https://cdimage.debian.org/cdimage/ports/ -- .''`. 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
debian-installer now available in Ports
Hi! Thanks to the recent efforts within the Debian Ports projects, debian-installer is finally available for the Debian Ports architectures [1]. Previously, the installer images had to be built manually because building on the buildds always required a testing repository to be available for a given architecture. With the latest release of debian-installer, the build falls back to the unstable and unreleased repositories for the required udebs. The generated d-i images for powerpc, kfreebsd-* and hurd-i386 can be found here: > ftp://ftp.debian.org/debian/dists/sid/main/installer-$ARCH For the remaining Ports architectures: > http://ftp.ports.debian.org/debian-ports/pool-$ARCH/main/d/debian-installer/ Now, since the process of building installer images no longer requires manual intervention, the process for building CD images has been simplified as well, still requires some manual work. Thus, I was wondering whether any volunteers would be willing to help building ISO images for the various architectures. A rough guide can be found in [2] from which the the d-i part can be omitted, however, a local mirror available through the filesystem is still necessary (see MIRROR in CONF.sh). So, reprepro needs to be used to set up a local mirror or the remote mirror needs to be mounted with a FUSE module or similar. In order to use the debian-installer images for building CD images, they have to be downloaded and extracted (for the remaining Ports architectures above) and placed into the directory pointed to by DI_DIR in the easy-build.sh script, e.g.: export DI_DIR="/srv/d-i/debian-installer/installer/build/tmp/cdrom/. Would be great if we could get several people work on this and create ISOs for alpha, hppa, powerpc, ppc64 and so on. Please note: It's not necessary to run debian-cd on the same architecture as the target architecture of the ISO images. Hence, using an amd64 host should be fine. Thanks, Adrian > [1] https://buildd.debian.org/status/package.php?p=debian-installer&suite=sid > [2] https://wiki.debian.org/PortsDocs/CreateDebianInstallerImages -- .''`. 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
Re: Porter roll call for Debian Stretch
On 09/30/2016 09:04 PM, Niels Thykier wrote: > As for "porter qualification" > = > > We got burned during the Jessie release, where a person answered the > roll call for sparc and we kept sparc as a release architecture for > Jessie. However, we ended up with a completely broken and unbootable > sparc kernel. To be fair, this happened because the upstream kernel development for SPARC came to an almost complete stop. There was basically only David Miller working on the port which turned out not to be enough. This isn't the case for PowerPC32 where upstream development is still very active because it's part of the PowerPC kernel which is maintained by IBM. PowerPC32 is also still quite popular which is why it still sees quite some testing in the wild. There are still new PowerPC32 designs based on embedded CPUs (FreeScale and the like). As for SPARC, Oracle is actually now heavily investing in Linux SPARC support, so even SPARC is getting back into shape which is why I hope we can add sparc64 as an official port soon. > That was an embarrassment to the Debian stability and quality > reputation that I never - ever - want to repeat. Well, mistakes happen and while I think it's good and important to learn from mistakes, we should not dramatize such issues. We have had worse issues like the OpenSSL entropy bug, for example, and we still managed to cope with the fallout in a very professional manner. > (For avoidance of doubt: I want to ensure that release architectures > "just work(tm)" and I have no desire to blame that volunteer). I don't think there is any concern regarding the powerpc port in this regard. wanna-build shows almost 11800 packages that are up-to-date which is a good indicator that the port is in good shape, both regarding the toolchain and various source packages which need architecture-specific adaptations like LibreOffice or JavaScript packages. On the other hand, some packages dropped support for PowerPC32 like Mono but this isn't a concern for most users, I would say. > If I am to support powerpc as a realease architecture for Stretch, I > need to know that there are *active* porters behind it committed to > keeping it in the working. People who would definitely catch such > issues long before the release. People who file bugs / submit patches etc. I agree and I'm actually doing that all the time. I always run unstable on my machines and constantly check wanna-build for build issues and report them upstream whenever they occur. I have helped dozens of such issues on "sh4" and "sparc64", for example. > If you need inspiration: Have a look at the [automatic testing of > ppc64el images]. Or the [arm64 machines on ci.debian.net] with > comparable results to amd64. This is the sort of thing that inspires > confidence in the ports for me and I think we should have vastly more of. I agree that would be nice to have. However, to be fair, we don't have that type of testing for all release architectures and to my current knowledge, automated testing of installation images is not a criteria for an architecture to maintain release status. My main argument for why we should keep the powerpc port is its popularity. If we look at the numbers from popcon [1], powerpc is still the fourth-most-popular port and I think we would disappoint many users if we were to drop the port for Stretch. Note that while ports like "arm64" or "ppc64el" receive lots of support, especially from companies, they still haven't reached the same popularity as the powerpc port for example. Heck, there are even more users for "hppa" and "sparc64" which both are just unofficial ports architectures. Thanks, Adrian > [1] http://popcon.debian.org/ -- .''`. 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
Re: Porter roll call for Debian Stretch
On 09/30/2016 06:08 PM, Niels Thykier wrote: > I strongly /suspect/ that "no porters" for powerpc will imply the > removal of powerpc for Stretch. It may or may not be moved to ports > (assuming someone is willing to support it there). So, I take this as a "no" for the offer from me and Christoph Biedel to take over the powerpc port for Stretch? I have quite some experience with working on ports and unlike what Matthias claimed, I'm not just maintaining a few buildds but also getting architecture-specific bugs fixed and so on. Is there any specific qualification I am missing? Thanks, 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
Re: Porter roll call for Debian Stretch
On 09/23/2016 03:54 PM, Matthias Klose wrote: > No, you are not maintaining powerpcspe as a release architecture, and that's > something different than building packages for some of the ports > architectures. > If you can get powerpcspe accepted as a release architecture, then maybe you > gain some credibility to maintain another release architecture ;) So, what are the criteria to be knighted to become a maintainer of powerpc? 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
Re: Porter roll call for Debian Stretch
On 09/20/2016 11:16 PM, Niels Thykier wrote: >- powerpc: No porter (RM blocker) I'd be happy to pick up powerpc to keep it for Stretch. I'm already maintaining powerpcspe which is very similar to powerpc. 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 signature.asc Description: OpenPGP digital signature
Re: The (uncalled for) toolchain maintainers roll call for stretch
On 09/10/2016 12:48 AM, Matthias Klose wrote: > Uncovered by the upstream primary and secondary platforms are the mips* > architectures and powerpc. For the uncovered archs I would expect somehow > more > and pro-active Debian maintenance, however I fail to see this happen. > > - see the history of ftbfs on the buildd page of the gcc-snapshot package > - see the status of the gcc-6 package for the pre-release uploads > - see the number of RC issues for binutils which came up with 2.27, >some still open. > - Toolchain packages are not watched by porters, and I can't track >every regression myself, however this is not done well by porters. > > On the recent Porter's call I didn't see any toolchain support for the powerpc > architecture. I would actually be happy to take over the powerpc port as its official porter. I'm already taking care of powerpcspe, so I think it would be a perfect fit. Let me know what needs to be done to make this happen! I don't want to see powerpc go too 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
Re: [Stretch] Status for architecture qualification
On 06/20/2016 04:15 PM, Lennart Sorensen wrote: > On Mon, Jun 20, 2016 at 04:11:32PM +0200, John Paul Adrian Glaubitz wrote: >> Well, we just did a full archive rebuild of "ppc64" to be able to >> support ppc64 on the e5500 cores by disabling AltiVec, didn't we? > > Well it is getting there. The archive rebuild is done and around 11200 packages are up-to-date. It's just the installer that needs work and someone needs to convince the release team that ppc64 is something we want as a release architecture. 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
Re: [Stretch] Status for architecture qualification
On 06/20/2016 04:05 PM, Lennart Sorensen wrote: > Also I suspect many users of 64 bit capable freescale chips > (e5500 and e6500 cores) are running 32 bit powerpc since they > don't have enough ram to actually really gain anything > from going to 64 bit, and the ppc64 port isn't done yet. Well, we just did a full archive rebuild of "ppc64" to be able to support ppc64 on the e5500 cores by disabling AltiVec, didn't we? 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
Re: [Stretch] Status for architecture qualification
On 06/18/2016 06:25 PM, William ML Leslie wrote: > In case it isn't clear, the number of users of the architecture is not part > of the qualification, it is the amount of maintenance pressure involved. > Package > maintainers have to put more effort into ensuring builds succeed for release > architectures, which detracts from other work that needs to be done. Not > being a > release architecture is perfectly fine. I maintain multiple architectures in Debian Ports, including m68k, powerpcspe, sh4, sparc64 and x32 and actually, it's not so much of a burden to maintain an architecture in Debian. Most of the packages don't need special attention and if they do, it's usually just poorly written code like people doing weird pointer arithmetics which provoke unaligned access or abuse C/C++ in other ways. If upstream developers in these cases cared more about code quality and adhering to the C/C++ standards, we would hardly ever have issues with any ports. Heck, even on m68k, most packages still build fine and they actually work. As long as an architecture is maintained upstream both in the kernel and the toolchain, there is absolutely no reason to not keep it in Debian unless there is no hardware available that can be used for buildds and porterboxes. Ports like Debian/GNU Hurd or Debian/kFreeBSD are a different story though as they need way more work to be able to make all sorts of packages work there. In the case of PowerPC, both the kernel and the toolchain are very well maintained, many packages like GHC have native support for the architecture and even rather problematic packages like Firefox/Thunderbird are supported. Plus, PowerPC packages can be built on the POWER8 virtual machines that IBM provides for Debian Developers in the cloud for free. We have one such machine set up for ppc64, for example. In any case, if PowerPC should ever be dropped as a release architecture, I will be more than happy to adopt it in Debian Ports. PS: If you see your package failing to build on any of the ports architectures and you want to fix it and need help, just let me know :). 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
Re: [Stretch] Status for architecture qualification
On 06/14/2016 09:06 AM, Philipp Kern wrote: > Yeah, but that's unfortunately one of the universal truths of this port. > I mean in theory sometimes they turn up on eBay and people try to make > them work[1]. Hilarious talk, thanks a lot for the link :). > It also seems true for other ports where we commonly relied on sponsors > to hand us replacements. But maybe it's only ppc64el these days, maybe > there are useful builds available for the others (including arm64 and > mips) on the market now. The hardware sponsoring is the main thing that keeps us from making sparc64 an official port, I would say. The state of the port itself is great: We recently even got LibreOffice running on sparc64 (patches not yet merged) and the port is quite popular, according to popcon, sparc64 has already more users than arm64 and some of the mips ports :). If we were to add sparc64 to Debian, we could rebuild the archive within a few weeks. We have one user who has two Sun T2 servers which are new-in-box (NIB), would those be ok to set up as machines for DSA? 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
Re: [Stretch] Status for architecture qualification
On 06/05/2016 02:00 PM, Holger Levsen wrote: > I'm not sure whether you are talking about source or binary packages but > sid/amd64 has over 24000 source packages and over 5 binary packages, > so I would call the above "on par". Or what am I missing? There are just around 12,000 source packages with arch:amd64 in sid: glaubitz@wuiet:~$ wanna-build -A sparc64 -d unstable --list=installed | wc -l 10828 glaubitz@wuiet:~$ wanna-build -A ppc64 -d unstable --list=installed | wc -l 10990 glaubitz@wuiet:~$ wanna-build -A amd64 -d unstable --list=installed | wc -l 12154 glaubitz@wuiet:~$ The rest is arch:all: glaubitz@wuiet:~$ wanna-build -A all -d unstable --list=installed | wc -l 15672 glaubitz@wuiet:~$ 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 signature.asc Description: OpenPGP digital signature
Re: [Stretch] Status for architecture qualification
ernel was recently turned into maintained state again after two developers involved with the J-Core project picked up the code, the latter issue will be hopefully resolved soon. It's already been put onto their TODO list. gcc upstream for SH is also still active, so both gcc-5 and gcc-6 work fine on sh4. Before I picked up sh4, there were actually many issues in the SH backend in gcc which prevented gcc-4.9/5/6 from being built on this architecture. With lots of patience, debugging, bug reporting and patching, gcc-5/6 are both in a healthy and usable state. Currently available SuperH hardware is rather slow and has usually not more than 512 MiB of RAM, so it wouldn't make sense to set up buildds and porterboxes with what is currently available. However, since the J-Core project is currently working on open source hardware, it might be possible that in the future, faster hardware becomes available at affordable prices. So it makes sense to keep an eye on sh4 and J-Core for future Debian releases. Thanks, Adrian PS: If other Debian people are interested in joining our efforts to work on the sparc64 port or making a Debian port for the J-Core happen, I would be happy to provide access to porterboxes. -- .''`. 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 signature.asc Description: OpenPGP digital signature
New ports signing key for 2016
Hello! I just noticed there is a new signing key for debian-ports, please update your buildds: glaubitz@z6:~/m68k> gpg --fingerprint B4C86482705A2CE1 pub 4096R/705A2CE1 2016-01-24 [expires: 2017-02-01] Key fingerprint = 69DD B056 0EA8 6E87 E835 99B3 B4C8 6482 705A 2CE1 uid Debian Ports Archive Automatic Signing Key (2016) glaubitz@z6:~/m68k> 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
Bug#811554: haskell-hslua: Please don't build-depend on libluajit-5.1-dev for unsupported architectures
Source: haskell-hslua Version: 0.4.1-4 Severity: important Hello! Currently, haskell-hslua is BD-Uninstallable for multiple architectures were it would actually build if it wasn't for the build dependency on libluajit-5.1-dev which is only supported on a limited number of architectures. I would therefore suggest to change the build dependency on libluajit-5.1-dev to use a whitelist instead of a blacklist, i.e. change debian/control as below: --- control.old 2016-01-19 20:48:43.0 +0100 +++ control.new 2016-01-19 20:50:18.661062876 +0100 @@ -10,7 +10,7 @@ ghc-prof, pkg-config, liblua5.1-0-dev, - libluajit-5.1-dev [!arm64 !ppc64el !s390x], + libluajit-5.1-dev [amd64 armel armhf i386 mips mipsel powerpc hurd-i386 kfreebsd-i386], libghc-hspec-dev, libghc-hspec-contrib-dev, libghc-hunit-dev, This would fix haskell-hslua being BD-Uninstallable on most ports architectures. Thanks, 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
Re: Time to change the debian-ports "list"?
I'm in favor of the old design because I think it's important to havw a list which can be used to make announcements about important issues that all porters should be aware of. It's not really that mails going to debian-ports@ appear that often. PS: Excuse my quoting style, currently on mobile. Adrian > On Jul 22, 2015, at 7:04 PM, Steve McIntyre wrote: > >> On Wed, Jul 22, 2015 at 05:38:17PM +0200, Wouter Verhelst wrote: >>> On Fri, Jul 17, 2015 at 01:40:20PM +0100, Steve McIntyre wrote: On Thu, Sep 11, 2014 at 12:51:29PM +0100, Steve McIntyre wrote: > On Wed, Sep 10, 2014 at 07:01:00PM +, Thorsten Glaser wrote: > Alexander Wirt dixit: > >> Could you please (technically) summarize what needs to be done from >> listmaster side? > > 1. Remove whatever debian-po...@lists.debian.org is right now > > 2. Create a new debian-po...@lists.debian.org mailing list which > works just like the other regular lists > > 3. Announce the new debian-po...@lists.debian.org so that people > can subscribe to it; document that there is no longer > an address to reach *all* ports but that people should > eMail the individual ports’ lists (and cross-post if > needed, but only to the amount needed), and that the > new debian-po...@lists.debian.org instead is a mailing list for > discussion about > a) debian-ports.org infrastructure > b) porting Debian in general > c) questions related to setting up a Debian port, > including wanna-build, buildd, etc. >> >> That seems like a bad idea to me, tbh. There will be people who won't >> notice that the meaning of debian-ports@ has changed, and who will try >> to use it with its old meaning. >> >> If there are problems with the current meaning of debian-ports, can't we >> just retire the old alias and create a list under a different name? > > Is there much point to that? I've not heard anybody at all speak up in > favour of the existing behaviour. If anybody does use try to use it > that way in future, the new list will most likely be the best place > for their mail to go... > > -- > Steve McIntyre, Cambridge, UK.st...@einval.com > "I used to be the first kid on the block wanting a cranial implant, > now I want to be the first with a cranial firewall. " -- Charlie Stross > > > -- > To UNSUBSCRIBE, email to debian-68k-requ...@lists.debian.org > with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org > Archive: https://lists.debian.org/20150722170456.gc5...@einval.com -- To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/a3f2133d-cea2-42d5-a4d3-5dacfe6ec...@physik.fu-berlin.de
Re: using build profiles breaks debian-ports
On 07/17/2015 09:31 AM, Thorsten Glaser wrote: > using build profiles breaks debian-ports architectures, all of them: What exactly is a build profile in this context? 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-bsd-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/55a8bda0.4010...@physik.fu-berlin.de
Re: Bug#399608: fixed in sysvinit 2.88dsf-59.1
Hi there! This upload most likely broke the build queue on several ports architectures because sysvinit-tools depend on a specific version of util-linux which wasn't build on the affected architectures yet [1]. I fixed sh4 and m68k manually, but sparc64 and powerpcspe are still stuck because they can't build the current version of util-linux. The problem is currently overshadowed on sparc64 by other BD-Uninstallable packages but it exists there as well most likely. To fix the issue, I had to build util-linux manually, wanna-build was unable to resolve the dependencies. Maybe the dependency on src:util-linux is incorrect and it should be just util-linux as src:util-linux apparently always depends on the most current version in the main archive instead of just any usable version in the archives? I don't know. In any case, I would love to fix the powerpcspe and sparc64 ports but I haven't got an account on any machine with these architectures yet so I can't help at the moment. I have asked for a sparc64 account but with no positive result so far. Anyway, just wanted to raise some awareness that this change broke the build queue on the ports and it might break again once util-linux is updated in the main archive again. Cheers, Adrian > [1] http://buildd.debian-ports.org/status/package.php?p=util-linux&suite=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-bsd-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/55588921.7070...@physik.fu-berlin.de
sh4 missing on packages.debian.org
Hi Aurelien! I just noticed that there seems to be something wrong with packages.debian.org regarding sh4. Many packages are not listed there as available even though they are built and installed. For example, src:glibc, has been fully built on sh4, yet: > https://packages.debian.org/sid/libc6 It's not there. It's also not installable anymore: yamato:~# apt-cache policy libc6 libc6: Installed: 2.19-9 Candidate: 2.19-9 Version table: *** 2.19-9 0 100 /var/lib/dpkg/status yamato:~# yamato:~# cat /etc/apt/sources.list deb http://ftp.debian-ports.org/debian/ unstable main deb http://ftp.debian-ports.org/debian/ unreleased main yamato:~# Do you know what could be wrong? 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-bsd-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/5409ed32.7080...@physik.fu-berlin.de
Re: Roll call for porters of architectures in sid and testing
Hello! On 09/25/2013 05:09 AM, Nobuhiro Iwamatsu wrote: > I am an active porter for the following architectures and I intend > to continue this for the lifetime of the jessie release: > > For sh4, I > - test packages on this architecture > - triage arch-specific bugs > - fix arch-related bugs > - maintain buildds I have joined Nobuhiro to help supporting the sh4 port. I am currently working on to reactive the build queue again. Needs-Build on sh4 is currently over 4000 and I need to build a couple of essential packages like gcc-4.9, gcc-4.8 and python2.7 manually to be able to resolve the dependency problems. gcc-4.9 has been building since Wednesday but it's looking good. I hope to have the packages uploaded over the weekend. 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-bsd-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/53e618fc.9070...@physik.fu-berlin.de
Re: [Pkg-zfsonlinux-devel] any news/reply regarding ZFS in NEW?
Hi! On 02/28/2014 06:23 PM, Yaroslav Halchenko wrote: > I am not an ftp-master but if I were one (and as a mentor for quite a > few projects) I would have preferred to have re-uploads because > > - ftp masters already looked at some past version We are talking about packages in NEW, those haven't usually been in the archives before. The case you are describing can only occur if an existing package is stuck in NEW because of new binary components, for example. > - having old and new versions eases to see what has changed (debdiff) > instead of starting all over or digging out previous version Not if there isn't any old version in the archives. > - shows active interest of original maintainers I don't understand this argument. Again, what I am saying is that if you upload something into NEW and you realized you messed something up or the package has been in the queue for quite some time now without any of the FTP masters having looked at the package yet and the maintainer has changed the packaging a lot in the meantime, I think it's the proper approach to ask the FTP team to mark the package as REJECT and upload a current version. This way the FTP team doesn't waste their time on reviewing a package which is going to be replaced very soon anyway. Especially when the packaging was considerably changed in the mean time. Who tells you that the maintainers didn't make any mistake in their new package version that would normally have triggered a REJECT by the FTP team, but the maintainers get to upload it into the archives anyway because there is already a version in unstable that has been accepted? Honestly, I think packages should automatically be removed from NEW after a certain grace period. This shouldn't be regarded as a REJECT for the package in general, but simply that no one has managed so far to review the package and it "fell out" of the queue. Helps keeping the packages in NEW "fresh" in my opinion. > for original uploader benefit is that package doesn't loose its order in > the NEW (IIRC). I don't see how this would be of any advantage. 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-bsd-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/5311ad8c.3000...@physik.fu-berlin.de
Re: [Pkg-zfsonlinux-devel] any news/reply regarding ZFS in NEW?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 02/28/2014 05:37 PM, Carlos Alberto Lopez Perez wrote: > I advise against this. The upload is to experimental, is OK if the > package has RC bugs. Why? If the maintainer has made some changes in the meantime while the package has been waiting in NEW and the FTP team hadn't yet the possibility to look at the package, why waste their time to review a package which is going to be redone anyway? > Let the ftp-master team accept the package first, and once that is > done we can upload a better version to unstable. But if you already start with a cleaner version in NEW, you have the chance to get a feedback on the current package revision instead of the old one. Makes much more sense to me. > In the meanwhile you can continue working on the package repository > as usual. I don't see how you couldn't when just asking for the package to be marked as REJECT. Like I said, I do that often and there is nothing wrong when the package hasn't even been looked at yet. I rather feel embarrassed about uploading a b0rked package into NEW. > However, I will wait for a resolution from ftp-master before > resuming my work on the package, because there is the possibility > of ftp-master not allowing the upload and I don't like to waste my > time. Just because your package is rejected doesn't mean you can't get it into unstable at all. Packages are rejected all the time. It just means the package is not *yet* fit for ACCEPT. 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 -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using GnuPG with Icedove - http://www.enigmail.net/ iQIcBAEBCAAGBQJTEMAZAAoJEHQmOzf1tfkTHYMP/3iYWbT/9r/HdJ/eQLCNFyvv Xk0tb1fRWUsvDrO2h+9I4IqDMD3UWxLtMvrGDkUrJEv5jXFsuWiMRRMRQTIN5wnS ImnjMJgrtUIohGmn0UF8yDkNXduc9GWX/DToh/74n6hjXSRja+qxg8gTf/Ts3nxL Th9AJLwSod6idgyC/keY64TkFLy5GKP73icMbF6SZCfwFyn5kFzPxarU+eDVnDDT Ynog2VFkIu4oG7YNYkQQDVwljY7wxsxEAl82CZt7D+gAHOVt6qG65iDJ7OuacJ0c McA5ZOnjIUf1EkX2xTzml8CddaF9pkJoXndqOObdsejdtxrRW97rb0Vo8+B7t7H8 NF8pSjooruRxNv08gF7g0m08++6Kh+qFFQmtHlAIirHhanffajX8r/LfVnMsK1Ts IfJbSd8BzNPKeeAraQy9axeudkDUMpRFYHq6c1+tM2Bh0maZrATVtwdEm5UBk8yM YRP+JUQY7n3ZYv13bEu5Ar1k0tpsIm51RLNFVQSowBOikPwABWZS78pr0dJ24sG4 y6whiqUno+93H0Jt9U3kkfVJgskYYZkpgSorZQMWMNCWQnmn9xrzI57iQjk2GTXP pM5ENvTANpSPE2bdxciNteQI/o7wCP0F8FovBNGXfKa8V2DYPS/mrExynE7nmFfa fpqhw8S4Bd/OPFyiroGX =qeZj -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/5310c01f.7040...@physik.fu-berlin.de
Re: [Pkg-zfsonlinux-devel] any news/reply regarding ZFS in NEW?
On 02/28/2014 04:13 PM, Turbo Fredriksson wrote: > Is it ok/allowed to upload a new package, even though the initial one is > still stuck in incoming? I suggest asking the FTP masters to mark the package as REJECT if you want to change something again. As long the package is still stuck in NEW (not incoming, this is where the package goes once it's been ACCEPTED), you can always have it rejected. It's the cleaner solution in my opinion instead of uselessly bumping the package revision to fix minor issues before the package isn't even ACCEPTED. 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-bsd-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/5310b7f6.60...@physik.fu-berlin.de
Re: How to get a new palo source package into unstable?
Hi Helge! On 01/11/2014 10:37 PM, Helge Deller wrote: > 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 mostly finished with palo now. I converted the package to the latest debhelper format, reformatted the copyright file to the new 1.0 format (still need to some missing copyright holders and verify the license is correct for all source files). I also added a README.source to explain what happened with palo after version 1.16. The remaining things are cleaning up the changelog, removing other cruft and updating files like README.Debian. Hope to get it finished by the weekend. I will send you the patches, have you ACK them and upload on Saturday or Sunday. 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-bsd-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/530f4e65.7080...@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-bsd-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
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=radeontop&suite=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-bsd-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: 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-bsd-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 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=hppa&suite=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-bsd-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 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-bsd-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/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-bsd-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: libgphoto2 and sane-backends FTBFS with libusb2-dev
On 07/25/2013 05:27 PM, Guillem Jover wrote: On Thu, 2013-07-25 at 14:16:57 +0200, John Paul Adrian Glaubitz wrote: On 07/25/2013 12:55 PM, Guillem Jover wrote: I'm preparing the upload right now. I'm ready and waiting with an updated libgphoto2 here. Just ping me once you have uploaded freebsd-libs and I'll be pushing libgphoto2 afterwards. It's now uploaded, it might take some time to get built on kfreebsd-i386 though. Awesome, thanks a lot! I'll check the buildds from time to time and once it's built, I'll push Markus' libgphoto2 as well :). 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-bsd-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/51f14440.1090...@physik.fu-berlin.de
Re: libgphoto2 and sane-backends FTBFS with libusb2-dev
On 07/25/2013 12:55 PM, Guillem Jover wrote: I'm preparing the upload right now. I'm ready and waiting with an updated libgphoto2 here. Just ping me once you have uploaded freebsd-libs and I'll be pushing libgphoto2 afterwards. 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-bsd-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/51f11739.6010...@physik.fu-berlin.de
Re: libgphoto2 and sane-backends FTBFS with libusb2-dev
On 07/25/2013 12:08 PM, Guillem Jover wrote: Petr, if you could commit the patch (so that authorship is preserved), I'll do an upload today (otherwise I'll commit myself, although I prefer to have proper attributtions on the VCS). Ok, that would be awesome. I have already set up a kfreebsd virtual machine with a pbuilder and everything to prepare an NMU of the package, but I'd rather prefer if any of the BSD guys goes ahead and makes the upload. If possible, could you guys let us know as soon as the package has been upload so we can go ahead and take care of libgphoto2, then initiate a rebuild of sane-backends on kfreebsd*? 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-bsd-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/51f0f9e5.5090...@physik.fu-berlin.de
Re: libgphoto2 and sane-backends FTBFS with libusb2-dev
Sorry for the bad formatting, sending from mobile. Anyways, what keeps us from just integrating a patch in the libusb2-dev Debian package and do a quick upload. Be it a normal upload or an NMU. Adrian > On Jul 24, 2013, at 11:47 PM, Markus Koschany wrote: > > On 24.07.2013 12:51, Petr Salinger wrote: > Please just fix ENODATA occurence, with updated libusb2-dev > it suffices to build libgphoto2. Hmm, Steven claimed it would work with just the patched libusb.h. >>> >>> Sorry if I said/implied that; but I had applied Markus' ENODATA fix >>> before testing for the other issue. So yes, both libusb2-dev and >>> libphoto2 need fixes (in that order). >> >> Exact order of fixing is not necessary. >> It is possible give-back libgphoto2 when fixed libusb2-dev >> will be in unstable. >> >> The ENODATA occurence have to be fixed. > > Steven, Petr, first of all many thanks for your quick response and your > patches! > > Right now I could successfully build libgphoto2 on kfreebsd-i386 with > the ENODATA and libusb.h patch. I will forward the former upstream. > > Although I do agree with Petr that requesting a give-back would be an > easy solution, I'm more concerned about the other libgphoto2 and > sane-backends packages on non-kfreebsd architectures which can't migrate > to testing at the moment. > > Do we have other options except waiting for a new release of libusb2-dev > and removing the outdated kfreebsd packages from testing to make > libgphoto2 and sane-backends swiftly migrate to testing? > > Regards, > > Markus > > -- To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/fe7718f6-a5fc-4d03-b8ef-891a37b5d...@physik.fu-berlin.de
Re: libgphoto2 and sane-backends FTBFS with libusb2-dev
On 07/24/2013 12:51 PM, Petr Salinger wrote: It is possible give-back libgphoto2 when fixed libusb2-dev will be in unstable. When is that going to happen? ;) The ENODATA occurence have to be fixed. Sure, we'll do that. We just want to make sure the package actually builds fine on the kfreebsd porterbox before uploading the package. We want to avoid uploading packages which FTBFS 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-bsd-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/51efb47a.4060...@physik.fu-berlin.de
Re: libgphoto2 and sane-backends FTBFS with libusb2-dev
On 07/23/2013 06:27 PM, Petr Salinger wrote: It tries to autodetect, but then fails in a later step: checking for libusb-1.0 to use... autodetect checking for LIBUSB1... yes checking libusb.h usability... no checking libusb.h presence... yes The attached patch may help with this. (I applied it directly to my system libusb.h). After this I got a successful build on kfreebsd-amd64 Independently prepared in our SVN as r4796 :-) Any chances this is going to be pushed to unstable soon so it's part of an updated libusb2-dev package? Please just fix ENODATA occurence, with updated libusb2-dev it suffices to build libgphoto2. Hmm, Steven claimed it would work with just the patched libusb.h. However, we'll just wait until libusb2-dev has been updated, then we'lll give it another shot and apply the ENODATA fix if necessary. 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-bsd-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/51ef9373.3030...@physik.fu-berlin.de
