abel.debian.org (armel/armhf porterbox) outage
Hi, our armel/armhf porterbox, abel, is suffering from hardware issues. Given the covid-19 crisis and restrictions in place in the UK, we don't yet know when a local admin will be able to tend to it. In the meantime, please use amdahl, the arm64 porterbox, which also has armel and armhf chroots. (We know this isn't always a suitable replacement, as some issues are specific to armv7 or earlier CPUs, so hopefully this situation is temporary.) Cheers, Julien, for DSA signature.asc Description: PGP signature
Re: linux: instability on arm64 MP30-AR1 servers
Control: found -1 4.19.28-2 On Wed, May 22, 2019 at 11:58:15 +0200, Julien Cristau wrote: > Source: linux > Version: 4.9.168-1 > Severity: important > X-Debbugs-Cc: debian-arm@lists.debian.org, debian-ad...@lists.debian.org > User: debian-ad...@lists.debian.org > Usertags: needed-by-DSA-Team > > Hi, > > ever since the 9.9 point release conova-node01.debian.org and > conova-node02.debian.org have been unstable. They run for an hour or > three, and then things go bad. Rebooting back to 4.9.144-3.1 makes them > stable again. > Still happening after upgrading to the stretch-backports kernel: [87461.376828] Bad mode in FIQ handler detected on CPU0, code 0x5600 -- SVC (AArch64) [87461.376834] Internal error: Oops - bad mode: 0 [#1] SMP [87461.389907] Modules linked in: openvswitch nsh nf_nat_ipv6 nf_nat_ipv4 nf_conncount nf_nat binfmt_misc nls_ascii nls_cp437 vfat fat dm_mod ip6t_REJECT nf_reject_ipv6 ip6table_filter ip6_tables ipt_REJECT nf_reject_ipv4 nfnetlink_log nfnetlink xt_NFLOG xt_tcpudp xt_hashlimit xt_multiport xt_conntrack efi_pstore nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 iptable_filter ast ttm drm_kms_helper drm xgene_hwmon i2c_algo_bit xgene_edac xgene_dma joydev evdev chaoskey sg xgene_rng mailbox_xgene_slimpro rng_core ipmi_ssif ipmi_devintf ipmi_msghandler efivars tun drbd lru_cache efivarfs ip_tables x_tables autofs4 ext4 crc16 mbcache jbd2 fscrypto raid10 raid456 async_raid6_recov async_memcpy async_pq async_xor async_tx hid_generic usbhid hid xor raid6_pq crc32c_generic libcrc32c raid0 multipath linear raid1 [87461.460161] md_mod sd_mod ahci_xgene libahci_platform libahci xhci_plat_hcd xgene_enet libata xhci_hcd i2c_xgene_slimpro marvell usbcore phy_xgene scsi_mod sdhci_of_arasan mdio_xgene sdhci_pltfm of_mdio cqhci fixed_phy sdhci libphy usb_common gpio_xgene_sb [87461.482839] CPU: 0 PID: 1557 Comm: ovsdb-server Not tainted 4.19.0-0.bpo.4-arm64 #1 Debian 4.19.28-2~bpo9+1 [87461.492528] Hardware name: GIGABYTE R120-P31/MP30-AR1, BIOS D7b 08/26/2016 [87461.499367] pstate: (nzcv daif -PAN -UAO) [87461.504132] pc : 897e2910 [87461.507427] lr : 897e2918 [87461.510722] sp : e32d4440 [87461.514016] x29: e32d4440 x28: 015a [87461.519301] x27: 89928c20 x26: [87461.524586] x25: e32d44f8 x24: e32d4528 [87461.529870] x23: 015a x22: 0090 [87461.535154] x21: d73fd286 x20: 0001 [87461.540439] x19: d743b560 x18: 0024 [87461.545723] x17: 897d7fc0 x16: 899238e0 [87461.551007] x15: 089e8439a422 x14: 0001 [87461.556291] x13: 5ce6a4fa x12: 0018 [87461.561576] x11: 26295eb7 x10: 000155a6 [87461.566860] x9 : d741f300 x8 : [87461.572144] x7 : 0010 x6 : [87461.577429] x5 : e32d42b8 x4 : d73f0410 [87461.582713] x3 : d743b568 x2 : d7403a20 [87461.587997] x1 : 0001 x0 : d743b560 [87461.593283] Process ovsdb-server (pid: 1557, stack limit = 0x03b97138) [87461.600468] ---[ end trace 2ab4838ec3817e8e ]--- [87461.606271] Bad mode in FIQ handler detected on CPU0, code 0x5600 -- SVC (AArch64) [87482.616230] rcu: INFO: rcu_sched detected stalls on CPUs/tasks: [87482.622133] rcu: 0-...0: (1 GPs behind) idle=9a6/1/0x4000 softirq=1153372/1153372 fqs=2456 [87482.631564] rcu: (detected by 4, t=5255 jiffies, g=6202645, q=14630) [87482.637973] Task dump for CPU 0: [87482.641182] ovsdb-serverR running task0 1557 1556 0x0002 [87482.648197] Call trace: [87482.650636] __switch_to+0x8c/0xd0 [87482.654018](null) Cheers, Julien
Bug#929359: linux: instability on arm64 MP30-AR1 servers
Source: linux Version: 4.9.168-1 Severity: important X-Debbugs-Cc: debian-arm@lists.debian.org, debian-ad...@lists.debian.org User: debian-ad...@lists.debian.org Usertags: needed-by-DSA-Team Hi, ever since the 9.9 point release conova-node01.debian.org and conova-node02.debian.org have been unstable. They run for an hour or three, and then things go bad. Rebooting back to 4.9.144-3.1 makes them stable again. Latest example: May 22 04:17:37 conova-node01/conova-node01/:::217.196.149.227 kernel: drbd resource3: PingAck did not arrive in time. May 22 04:17:37 conova-node01/conova-node01/:::217.196.149.227 kernel: drbd resource3: peer( Secondary -> Unknown ) conn( Connected -> NetworkFailure ) pdsk( UpToDate -> DUnknown ) May 22 04:17:37 conova-node01/conova-node01/:::217.196.149.227 kernel: block drbd3: new current UUID 3EA2D1FA6B3ACD47:0BEBDA613EA56FD7:D5BF70E0AA6560C5:D5BE70E0AA6560C5 May 22 04:17:37 conova-node01/conova-node01/:::217.196.149.227 kernel: drbd resource3: ack_receiver terminated May 22 04:17:37 conova-node01/conova-node01/:::217.196.149.227 kernel: drbd resource3: Terminating drbd_a_resource May 22 04:17:37 conova-node01/conova-node01/:::217.196.149.227 kernel: drbd resource3: Connection closed May 22 04:17:37 conova-node01/conova-node01/:::217.196.149.227 kernel: drbd resource3: conn( NetworkFailure -> Unconnected ) May 22 04:17:37 conova-node01/conova-node01/:::217.196.149.227 kernel: drbd resource3: receiver terminated May 22 04:17:37 conova-node01/conova-node01/:::217.196.149.227 kernel: drbd resource3: Restarting receiver thread May 22 04:17:37 conova-node01/conova-node01/:::217.196.149.227 kernel: drbd resource3: receiver (re)started May 22 04:17:37 conova-node01/conova-node01/:::217.196.149.227 kernel: drbd resource3: conn( Unconnected -> WFConnection ) May 22 04:17:38 conova-node01/conova-node01/:::217.196.149.227 kernel: drbd resource3: Handshake successful: Agreed network protocol version 101 May 22 04:17:38 conova-node01/conova-node01/:::217.196.149.227 kernel: drbd resource3: Feature flags enabled on protocol level: 0x7 TRIM THIN_RESYNC WRITE_SAME. May 22 04:17:38 conova-node01/conova-node01/:::217.196.149.227 kernel: drbd resource3: Peer authenticated using 16 bytes HMAC May 22 04:17:38 conova-node01/conova-node01/:::217.196.149.227 kernel: drbd resource3: conn( WFConnection -> WFReportParams ) May 22 04:17:38 conova-node01/conova-node01/:::217.196.149.227 kernel: drbd resource3: Starting ack_recv thread (from drbd_r_resource [8449]) May 22 04:17:38 conova-node01/conova-node01/:::217.196.149.227 kernel: block drbd3: drbd_sync_handshake: May 22 04:17:38 conova-node01/conova-node01/:::217.196.149.227 kernel: block drbd3: self 3EA2D1FA6B3ACD47:0BEBDA613EA56FD7:D5BF70E0AA6560C5:D5BE70E0AA6560C5 bits:4 flags:0 May 22 04:17:38 conova-node01/conova-node01/:::217.196.149.227 kernel: block drbd3: peer 0BEBDA613EA56FD6::D5BF70E0AA6560C4:D5BE70E0AA6560C5 bits:0 flags:0 May 22 04:17:38 conova-node01/conova-node01/:::217.196.149.227 kernel: block drbd3: uuid_compare()=1 by rule 70 May 22 04:17:38 conova-node01/conova-node01/:::217.196.149.227 kernel: block drbd3: peer( Unknown -> Secondary ) conn( WFReportParams -> WFBitMapS ) pdsk( DUnknown -> Consistent ) May 22 04:17:38 conova-node01/conova-node01/:::217.196.149.227 kernel: block drbd3: send bitmap stats [Bytes(packets)]: plain 0(0), RLE 28(1), total 28; compression: 100.0% May 22 04:17:38 conova-node01/conova-node01/:::217.196.149.227 kernel: block drbd3: receive bitmap stats [Bytes(packets)]: plain 0(0), RLE 28(1), total 28; compression: 100.0% May 22 04:17:38 conova-node01/conova-node01/:::217.196.149.227 kernel: block drbd3: helper command: /bin/true before-resync-source minor-3 May 22 04:17:38 conova-node01/conova-node01/:::217.196.149.227 kernel: block drbd3: helper command: /bin/true before-resync-source minor-3 exit code 0 (0x0) May 22 04:17:38 conova-node01/conova-node01/:::217.196.149.227 kernel: block drbd3: conn( WFBitMapS -> SyncSource ) pdsk( Consistent -> Inconsistent ) May 22 04:17:38 conova-node01/conova-node01/:::217.196.149.227 kernel: block drbd3: Began resync as SyncSource (will sync 16 KB [4 bits set]). May 22 04:17:38 conova-node01/conova-node01/:::217.196.149.227 kernel: block drbd3: updated sync UUID 3EA2D1FA6B3ACD47:0BECDA613EA56FD7:0BEBDA613EA56FD7:D5BF70E0AA6560C5 May 22 04:17:38 conova-node01/conova-node01/:::217.196.149.227 kernel: block drbd3: Resync done (total 1 sec; paused 0 sec; 16 K/sec) May 22 04:17:38 conova-node01/conova-node01/:::217.196.149.227 kernel: block drbd3: updated UUIDs 3EA2D1FA6B3ACD47::0BECDA613EA56FD7:0BEBDA613EA56FD7 May 22 04:17:38 conova-node01/conova-node01/:::217.196.149.227 kernel: block drbd3: conn( SyncSource -> Connected ) pdsk( Inconsistent -> UpToDate ) May 22
Re: Bug#881333: Qt with GLES on arm64 maintainer's decision - Was:: Upcoming Qt switch to OpenGL ES on arm64
[dropping -devel, adding mesa and kde maintainers instead] On 11/27/18 5:42 PM, Steve Langasek wrote: > On Mon, Nov 26, 2018 at 03:39:03PM -0800, Keith Packard wrote: >> Steve Langasek writes: > >>> Long ago I heard rumors of development work on mesa that would allow it to >>> function as a proxy library, so that apps would link against libGL as needed >>> and the GL implementation would use a hardware-accelerated GLES driver where >>> possible, falling back to software GL where necessary. > >> This seems unlikely -- I believe GLES and GL have different semantics in >> a few places which makes implementing GL on GLES inefficient; mostly >> that GLES is missing stuff that GL applications often use, but I think >> there are places where GLES is just different, including in how GLSL >> works. > > Perhaps that explains why no one ever actually succeeded in implementing it, > then? > > Thanks for the context. > >> I haven't tried, but I would expect that applications could use both GL >> and GLES APIs at the same time, even to the same window. If this does >> work with Mesa, then linking Qt against GLES wouldn't restrict >> applications using free drivers at least? > > My recollection is that this becomes a practical problem of applications > that want to use both Qt and GL being unbuildable due to namespace > collisions at build time. > Do you know if there have been attempts at resolving those collisions upstream (either Qt or mesa / khronos)? I seem to remember a couple of bug reports against mesa on the Debian side but am curious about any escalations. Cheers, Julien
Re: Upcoming Qt switch to OpenGL ES on arm64
On 11/23/18 12:18 PM, Dmitry Shachnev wrote: > On Thu, Nov 22, 2018 at 11:05:27PM +0100, Julien Cristau wrote: >> At least mesa drivers can be used for desktop GL or GLESv2 just fine, >> AFAIK. Maybe the answer for Qt is to switch to GLESv2 for all >> architectures, to stop the special-casing madness, instead of making it >> spread? :) > > According to config_help.txt [1], Qt uses ES2 by default on Windows. > It probably means that it will work fine with most desktop video cards. > > But as Lisandro says, such a change in Debian will break many packages > (which are currently broken on ARM only), so we are definitely not > considering it at this point. > Why is it OK to break them on arm64 if it's not OK to break them on amd64? Do you have a list of those packages? Cheers, Julien
Re: Upcoming Qt switch to OpenGL ES on arm64
On 11/22/18 10:30 PM, Marcin Juszkiewicz wrote: > W dniu 22.11.2018 o 19:37, Dmitry Shachnev pisze: > >> The Qt framework can be built either with “desktop” OpenGL, or with OpenGL ES >> support. At the moment we are building it with OpenGL ES on armel and armhf, >> and with desktop OpenGL on all other architectures. >> >> However we have received a request [1] from two different persons to add >> arm64 >> to the list of architectures where OpenGL ES is used. >> >> We want your feedback! If you are using an arm64 device or board with Qt, >> please let us know your opinion about this change, by replying to this mail >> or to [1], and describe your use case. > > Does it mean that arm64 box with PCI Express graphics card will be not > able to use Qt based software? I can put Radeon or NVidia card into my > box and use it as a normal OpenGL accelerated desktop (did that already > few years ago). > At least mesa drivers can be used for desktop GL or GLESv2 just fine, AFAIK. Maybe the answer for Qt is to switch to GLESv2 for all architectures, to stop the special-casing madness, instead of making it spread? :) Cheers, Julien
Re: Please gb ktexteditor/armhf
[cc += debian-arm] On 09/09/2018 11:15 PM, Pino Toscano wrote: > Hi, > > the 5.49.0-2 build of ktexteditor failed because two unit tests > SIGBUS'ed. OTOH, armel worked, and my tests on the abel armhf porterbox > worked fine. (While on harris GCC ICEd really a lot, and I gave up > after the 4 ICE in a row...). > > So please giveback ktexteditor_5.49.0-2/armhf, hoping it was some kind > of transient failure... > I doubt it's transient failure (it failed again), more likely to be the fact that arm-arm-01 is arm64 hardware. You may want to try amdahl's armhf chroot rather than abel. The arm porters may be able to help too. Cheers, Julien
Re: Arch qualification for buster: call for DSA, Security, toolchain concerns
On 06/27/2018 10:03 PM, Niels Thykier wrote: > Hi, > > > As part of the interim architecture qualification for buster, we request > that DSA, the security team and the toolchain maintainers review and > update their list of known concerns for buster release architectures. > Everyone, please avoid followups to debian-po...@lists.debian.org. Unless something is relevant to *all* architectures (hint: discussion of riscv or arm issues don't qualify), keep replies to the appropriate port-specific mailing list. Thanks, Julien
Re: Arch qualification for buster: call for DSA, Security, toolchain concernsj
[s/debian-ports/debian-arm/] On 06/29/2018 09:16 AM, Uwe Kleine-König wrote: > Hello, > > On Wed, Jun 27, 2018 at 08:03:00PM +, Niels Thykier wrote: >> armel/armhf: >> >> >> * Undesirable to keep the hardware running beyond 2020. armhf VM >>support uncertain. (DSA) >>- Source: [DSA Sprint report] >> >> [DSA Sprint report]: >> https://lists.debian.org/debian-project/2018/02/msg4.html > > In this report Julien Cristau 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. > > If the concerns are mostly about the hardware not being rackable, there > is a rackable NAS by Netgear: > > > https://www.netgear.com/business/products/storage/readynas/RN2120.aspx#tab-techspecs > > with an armhf cpu. Not sure if cpu speed (1.2 GHz) and available RAM (2 > GiB) are good enough. The machine can run mainline Linux[1]. I think > U-Boot doesn't support this machine in mainline though. > Rackable, while good, is only part of it. The main part is remote management. I'm not seeing any mention of ipmi or anything like that in the datasheet? 2G is also way too little memory these days for a new buildd. Cheers, Julien
Re: Anyone using stretch/buster/sid on ARMv4t ?
On 11/05/2017 10:32 PM, Adrian Bunk wrote: > Hi, > > for the armel port in buster the question of raising the baseline came up. > > 20 years ago you could go into a shop and buy a mobile phone > with a CPU supported by the armel port in stretch. > > Roger Shimizu is doing a great job on ARMv5 hardware and I've seen bug > reports from users on ARMv5 hardware in stretch, so it is clear that > ARMv5 should stay supported (and of course also ARMv6 and ARMv7). > That's not clear to me at all. Keeping armel on life support for 2 more years is a significant drain on DSA and our hosters, for questionable benefit. Cheers, Julien
Re: armel after Stretch
On 12/09/2016 05:22 PM, Wookey wrote: > We can do poor-mans partial arch by just being fairly agressive about > disabling armel for packages that are broken or not suitable. Not very > clever or efficient, but it is easy to do and requires no infra or > tooling changes at all. So long as someone is volunteering for that > (easy but unexciting) work that could work. > We wouldn't necessarily want to call the result a Debian release, though. Cheers, Julien
Re: Supporting armel/armhf in wheezy-lts
On Sat, Apr 23, 2016 at 14:41:30 +0200, Raphael Hertzog wrote: > I have also been looking at ways to bring the "LTS funding" closer to Debian > and to find a way to join all this in the Debian Partner program but we > don't have many volunteers interested in this work. We discussed it a bit > last year during Debconf with Luca Filippozi, Martin Krafft and Neil > McGovern, but this never went further. And I obviously don't want to be > leading this project due to the clear conflict of interest that I would > have... > I think one of the contentious points is how "Freexian raising funds to work on Debian LTS" is already too close to calling itself "Debian LTS fundraising", so I'm not sure bringing them closer would alleviate anyone's concerns. Cheers, Julien
Re: GL/gl.h, Qt5 and arm: FTBFS
On Mon, Mar 24, 2014 at 15:10:25 -0300, Lisandro Damián Nicanor Pérez Meyer wrote: Hi! I'm trying to find a solution for the FTBFS of qantenna on arm* [0][1] that fits the best to everyone. This issue seems to be very similar to a older thread including both GL/gl.h and cogl/cogl.h fails on armel and armhf [2], but I failed to see how that was resolved. As far as I can tell, http://patch-tracker.debian.org/patch/series/view/toonloop/2.2.0-1/0004-fix_arm.patch should have solved it. The FTBFSs are due to conflicting declarations for GLdouble, GLsizeiptr and GLintptr. Basically the problem might boild down to the fact that Qt5 is built using es2 instead of the desktop opengl which, to the best of my knowledge, it's standard OpenGL 2.0. These are the possible solutions I think could be taken: a) Switch Qt5 to use desktop OpenGL on arm*. I have tested this on harris.d.o and works OK. As a pro, it means that other apps will not have porting issues like this. As a con, it might mean that all the OpenGL stuff will be done by software though, am I correct? Sounds about right. b) (supossing it's possible) provide es2 versions of mesa-common-dev, libglu1- mesa-dev et al. and build against that on arm* d) (also supossing it's possible) do not consider the FTBFS not RC (or allow it's transition even if it's RC) until a better fix could be done. Please note that I did not include porting the app because, as I understand it, there is no es2-enabled GLU available, or at least on Debian. I'm inclined for option a, but maybe you can provide alternative solutions. As a fallback (if it's possible at all) I would take option d, but that might be needed for other apps in the no-so-distant future, when we will start to see massive porting from Qt4 to Qt5. I'd very much like to avoid b. The GLU spec (http://www.opengl.org/registry/doc/glu1.3.pdf) seems very much tied to old OpenGL. I didn't think GLU was still a thing used by any modern toolkit/app, though, so I'm surprised you get to choose between GLU and Qt5 is a problem. Cheers, Julien signature.asc Description: Digital signature
Re: GL/gl.h, Qt5 and arm: FTBFS
On Tue, Mar 25, 2014 at 07:46:06 +0800, Paul Wise wrote: On Tue, Mar 25, 2014 at 3:43 AM, Steve Langasek wrote: Correct. It is rare to find accelerated OpenGL drivers for ARM; almost all the drivers out there, particularly for recent hardware, will be GLES2 instead. That is changing slowly, Qualcomm Adreno GPUs are apparently now supported by mesa via the code merged from the freedreno reverse engineering project. There are also reverse engineering projects for most of the other ARM GPUs at varying levels of completion. It would be great if Debian people owning ARM devices would start looking at and packaging them. You'll most likely still want to target GLES rather than desktop GL... Cheers, Julien signature.asc Description: Digital signature
Re: maintainer communication
On Mon, Dec 23, 2013 at 22:14:00 +, Thorsten Glaser wrote: My intent in _this_ thread was to get a discussion among debian-ports.org users started for best practices of how to communicate with package maintainers in Debian. Sorry for being unclear there. I had hoped for hints ☺ since I know my communication skills lack somewhat. debian-po...@lists.debian.org is an alias for *all* debian-$arch lists for debian architectures. It has nothing to do with debian-ports.org. If you want a list for debian-ports.org users go create one, but please don't abuse this one. Thanks, Julien signature.asc Description: Digital signature
Re: Bits from ARM porters
On Tue, Dec 3, 2013 at 11:42:56 +, Dmitrijs Ledkovs wrote: On 2 December 2013 23:08, Hector Oron hector.o...@gmail.com wrote: 5 arm64 Debian port support ═══ If Debian is unable to find ARM 64-bit hardware before Jessie gets frozen, it likely won't be Jessie supported. What is the opportunity cost here? Are there no machine available within budget? If that's the case, what's the current budget that Debian Project can contribute, and what's the shortage to buy ARM 64-bit hardware *today*? I would hope that's 0. If there's available arm64 hw and there are companies interested in a Debian arm64 port then I'd think they can sponsor hw. Cheers, Julien signature.asc Description: Digital signature
Bug#683425: release-notes: new in wheezy: armhf
Package: release-notes Severity: important Tags: wheezy help The release notes for wheezy need to have some text about the new armhf arch. Some help with this from arm people would be welcome. Cheers, Julien signature.asc Description: Digital signature
Re: including both GL/gl.h and cogl/cogl.h fails on armel and armhf
On Sat, Dec 31, 2011 at 11:42:26 +0200, Konstantinos Margaritis wrote: On 31 December 2011 02:14, Josselin Mouette j...@debian.org wrote: It is cogl which is at fault. Being built against GLES breaks basically everything that depends on it. armel/armhf only support GLES in hardware so it does make sense to enable it for those platforms. We should try and fix that support where broken, not disable it. That means maintainers of all reverse deps have to special-case a platform where they can't test anything. Which means those packages will be broken. I think this arm special-case in clutter/cogl is a bad idea. Maybe we should just stop building mesa on arm entirely. Cheers, Julien -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20111231114442.gn3...@radis.cristau.org
Re: including both GL/gl.h and cogl/cogl.h fails on armel and armhf
On Sat, Dec 31, 2011 at 12:58:42 +, peter green wrote: The debian rc policy clearly states Packages must be supported on as many architectures as is reasonably possible. Right now, it's not reasonably possible to have working 3d on arm in Debian, so... The other option, which might make everyone happy, is to just switch to GLES on all platforms. Needs a lot of testing to make sure the desktop doesn't break horribly, but at least it won't have stupid special cases. Cheers, Julien -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20111231131629.go3...@radis.cristau.org
Re: ruby1.9.1 migration to testing
On Sun, Oct 23, 2011 at 14:11:26 +0200, Lucas Nussbaum wrote: At this point, I'm confident that we can reach a (at least partially) working Ruby on kfreebsd, sparc and armel at some point. I'm less confident about ia64. Question: what should we do in the meantime? Options are: (1) keep 1.9.3~rc1-1 in unstable until all the issues are fixed. (2) build it with nocheck on ia64, sparc, kfreebsd, so that it can migrate. (3) disable test suite on ia64, sparc, kfreebsd until issues are fixed, so that it can migrate. (4) remove ruby1.9.1 binary packages on ia64, sparc, kfreebsd for now (not really an option due to the large number of reverse dependencies). The version in testing is also affected by most of those issues, and was uploaded by porters after a nocheck build on some architectures. My preference is 3,2,4,1 but I wanted to check with you before going forward. I don't think knowingly shipping a broken package is ok, which means 1 and 4 have my preference. I'm assuming the testsuite failures really mean ruby is broken on those archs; if the failures were for fringe features then my answer would probably be different. I'm also assuming the current version in testing works better; if not then there's no point keeping the newer one out because of this. Cheers, Julien -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/2003202748.ge3...@radis.liafa.jussieu.fr
Re: DSO linking changes for wheezy
On Mon, Nov 15, 2010 at 21:29:07 -0500, Matt Turner wrote: On Mon, Nov 15, 2010 at 8:15 PM, Samuel Thibault sthiba...@debian.org wrote: Matt Turner, le Mon 15 Nov 2010 19:51:10 -0500, a écrit : On Mon, Nov 15, 2010 at 7:24 PM, Roger Leigh rle...@codelibre.net wrote: What's the actual problem --as-needed is trying to solve? The answer is mainly unwanted libraries being linked in as a result of using pkg-config (and various other -config variants), though there are other, lesser, culprits. The pkg-config .pc files for gtk, gnome and other libraries add in many libraries, most of which aren't typically needed. The solution: fix the .pc files! Using --as-needed is merely papering over the actual root problem. It fixes the symptoms, but it's not addressing the actual cause. The number of packages providing broken .pc files is not large, and the number breaking due to relying on this brokenness is likely just as small. I can't see why you think --as-needed is fundamentally wrong or unnecessary. Check out http://www.gentoo.org/proj/en/qa/asneeded.xml --as-needed has saved tons of time for upgrades like Cairo in Gentoo, where Cairo had been linked to glitz which is now useless and gone. Not a problem, if Cairo was properly exposing the dep. So when people upgraded Cairo, all the software that linked against it (and also unnecessarily linked against glitz) Why did it get linked against glitz? That's where the problem is. I think because -lglitz was in cairo's .pc file. That should be fixed by removing -lglitz from cairo's .pc file, not by passing --as-needed to the linker. Cheers, Julien signature.asc Description: Digital signature
Re: DSO linking changes for wheezy
On Tue, Nov 16, 2010 at 01:14:09 +0100, Matthias Klose wrote: On 14.11.2010 13:19, Julien Cristau wrote: On Fri, Oct 29, 2010 at 15:43:57 +0200, Matthias Klose wrote: For wheezy I'm planning to change the linking behaviour for DSOs (turning on --as-needed and --no-copy-dt-needed-entries. The rationale is summarized in http://wiki.debian.org/ToolChain/DSOLinking. I would like to know about issues with these changes on some of the Debian ports, and if we need to disable one of these changes on some port. --no-add-needed sounds like it'll cause a *lot* of build failures for no particular gain. I don't think it's a good idea. I think it is. Besides fixing potential bugs, else you'll never be able to use gold as the linker. See the already filed bug reports. Exactly, see the already filed reports. You don't need to turn them into build failures before you can file reports and send patches. Cheers, Julien signature.asc Description: Digital signature
Re: DSO linking changes for wheezy
On Fri, Oct 29, 2010 at 15:43:57 +0200, Matthias Klose wrote: For wheezy I'm planning to change the linking behaviour for DSOs (turning on --as-needed and --no-copy-dt-needed-entries. The rationale is summarized in http://wiki.debian.org/ToolChain/DSOLinking. I would like to know about issues with these changes on some of the Debian ports, and if we need to disable one of these changes on some port. --no-add-needed sounds like it'll cause a *lot* of build failures for no particular gain. I don't think it's a good idea. Cheers, Julien signature.asc Description: Digital signature
Re: Please reschedule build for knetworkmanager_0.2-2
On Sun, Oct 14, 2007 at 17:22:14 +0200, Michael Biebl wrote: Hi, knetworkmanager_0.2-1 has been held back from entering testing because it wasn't built for the arm, hppa and sparc architecture for quite some time. Please reschedule builds for these architectures. Hi, The contact address for buildd admins is [EMAIL PROTECTED], not [EMAIL PROTECTED] Cheers, Julien -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
