Shutdown button not working on LXDE environment
Hi all, I am working on porting debian wheezy to a13-olinuxino board. I am using LXDE as desktop environment, openbox as windows manager. Shut Down button doesn't work after I installed cairo-dock. Earlier I had SysVinit as service manager, after which I have installed systemd. From the terminal I can shutdown using either systemctl shutdown or init 0. Does that mean I have two service managers ? can anyone help me ? Regards, Divya Subramanian
Re: Bug#746761: libgtk2-perl: Sometimes FTBFS (t/GtkCellRenderer.t fails) on mips, mipsel and armhf
Hi, dear mips and arm porters, intrig...@debian.org wrote (03 May 2014 11:05:09 GMT) : since April 2010 (1.1.221-6), libgtk2-perl sometimes fails to build on the armhf, mips and mipsel architectures, due to a failing test (t/GtkCellRenderer.t). I did not find any similar failure on other architectures. I am going to report this upstream. Dear porters, any idea what could be wrong with this package, or its dependencies? Sorry to bother you again, but here's just a gentle ping: this FTBFS has now been blocking the migration of libgtk2-perl to testing for two weeks. Note that there's been no progress yet on the corresponding upstream bug I filed: https://bugzilla.gnome.org/show_bug.cgi?id=729453 Cheers, -- intrigeri | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/85y4y3z8bx@boum.org
Re: Shutdown button not working on LXDE environment
Sounds like you installed systemd and are running that. systemd supports `systemctl poweroff`, `init 0` and `shutdown -h now` as shutdown methods. I suggest you look at the apt history (/var/log/apt/history.log) and try to figure out if any hardware-specific packages were removed. For example on amd64 machines, acpid/acpi-support/acpi-support-base are responsible for turning the button press event into shutdown. -- bye, pabs http://wiki.debian.org/PaulWise -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CAKTje6HnBwRn6ZH2onB6pcSEj1=9b7NuoRaJiOD-=p-umv0...@mail.gmail.com
Re: Debian on Synology Armada 370/XP NAS boxes
On Wed, 2014-05-14 at 19:16 +0200, Alexander Pohl wrote: Ideally, one would have to supply an u-boot version which has the Grub API enabled and then to chain load Grub from there, Ideally perhaps but in reality there are various issues with running grub on u-boot (the u-boot API is pretty broken, grub is not relocatable etc), I at least have given up on that path. which in turns loads Debian initramfs and kernel images. This way keeping the system up to date with newer kernels would be easy as this is all handled by Grub. The current tool we have for doing this is flash-kernel. Adding support should just be a case of figuring out the correct stanza for the machine. It supports various modes, including copying kernel+flash to dedicated flash partitions (either raw or with a filesystem), writing a boot.scr, appending a device-tree as necessary etc. It should be possible to integrate with the factory u-boot. Even if you are keen to go the grub route I would suggest getting things working via flash-kernel first to enable these systems to be used, and then treat the grub thing as a future thing. u-boot folks seem to be standardising on parsing the extlinux/syslinux config file format for this stuff, I might take a look at whether the extlinux-update script can be made available on ARM at some point (it's currently in an x86 only package). The problem for development and testing I see is that the u-boot image supplied by Synology does not have the Grub API enabled, so one has to flash a new version of u-boot first, which is targeted for the specific platform. The bootrom of the DS213j does not support the uart boot method implemented in kwboot, so if the update of the u-boot image fails one is left with a bricked unit. One could try to program the SPI flash in-circuit, but this might not work. With the flash-kernel method there should be no need to reflash grub, unless the factory one is horribly broken somehow. Could you please elaborate on the reasons why Synology boxes are not yet supported by the Debian installer images and where the problems are to implement support in the future. AFAIK there are none. These things happen when interested people send patches. Ian. -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1400150824.4386.37.ca...@kazak.uk.xensource.com
Re: Shutdown button not working on LXDE environment
I checked it but no such packages are removed. Is there any other way to do so ? Where does the shut down button from application menu mapsto ? Regards, Divya Subramanian On Thu, May 15, 2014 at 3:15 PM, Paul Wise p...@debian.org wrote: Sounds like you installed systemd and are running that. systemd supports `systemctl poweroff`, `init 0` and `shutdown -h now` as shutdown methods. I suggest you look at the apt history (/var/log/apt/history.log) and try to figure out if any hardware-specific packages were removed. For example on amd64 machines, acpid/acpi-support/acpi-support-base are responsible for turning the button press event into shutdown. -- bye, pabs http://wiki.debian.org/PaulWise -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CAKTje6HnBwRn6ZH2onB6pcSEj1=9b7NuoRaJiOD-=p-umv0...@mail.gmail.com
Re: arm64 update - help wanted
[Dropping d-devel] On 15-05-14 03:10, Wookey wrote: Also if anyone has expertise in language porting we'd like to hear from you. Below is the list of languages we believe still need porting to arm64: Anyone who is interested in doing this work, or just has some idea of how much work is involved, do please pipe up (I don't know if each of these is 6 months or 6 minutes). There is a porter box available. Pascal We have a list for that. Abou, do you know the status of upstream support for arm64? Do you think it is worth it to try out building on the porter box? Do you have any idea what would be involved? Paul signature.asc Description: OpenPGP digital signature
Re: [Pkg-pascal-devel] arm64 update - help wanted
Hi All, On Thu, 2014-05-15 at 19:31 +0200, Paul Gevers wrote: [Dropping d-devel] On 15-05-14 03:10, Wookey wrote: Also if anyone has expertise in language porting we'd like to hear from you. Below is the list of languages we believe still need porting to arm64: Anyone who is interested in doing this work, or just has some idea of how much work is involved, do please pipe up (I don't know if each of these is 6 months or 6 minutes). There is a porter box available. Pascal We have a list for that. Abou, do you know the status of upstream support for arm64? Do you think it is worth it to try out building on the porter box? Do you have any idea what would be involved? As i can see in the makefile there is no arm64 in CPU_TARGET when grepping make files: ifeq ($(CPU_TARGET),arm) ifeq ($(CPU_TARGET),i386) ifeq ($(CPU_TARGET),mipsel) ifeq ($(CPU_TARGET),m68k) ifeq ($(CPU_TARGET),i386) ifeq ($(CPU_TARGET),x86_64) ifeq ($(CPU_TARGET),sparc) ifeq ($(CPU_TARGET),powerpc) ifeq ($(CPU_TARGET),powerpc64) ifeq ($(CPU_TARGET),alpha) ifeq ($(CPU_TARGET),arm) ifeq ($(CPU_TARGET),armeb) ifeq ($(CPU_TARGET),jvm) ifeq ($(CPU_TARGET),mips) ifeq ($(CPU_TARGET),mipsel) ifeq ($(CPU_TARGET),i8086) ifeq ($(CPU_TARGET),avr) ifneq ($(CPU_TARGET),jvm) ifneq ($(CPU_TARGET),jvm) ifeq ($(CPU_TARGET),jvm) ifneq ($(CPU_TARGET),$(CPU_SOURCE)) ifeq ($(CPU_TARGET),i386) ifeq ($(CPU_TARGET),powerpc) ifeq ($(CPU_TARGET),x86_64) However I'm not sure and thus I'm cc-ing upstream for more accurate answer. Cheers, Abou Al Montacir, signature.asc Description: This is a digitally signed message part
Re: arm64 update - help wanted
On Thu, 2014-05-15 at 02:10 +0100, Wookey wrote: Also if anyone has expertise in language porting we'd like to hear from you. Below is the list of languages we believe still need porting to arm64: Ruby wasn't on the list, is that under control? Ruby seems to be at the bottom of the build-dep chain for the kernel (linux-patchutils-rpm-libsemanage-ruby). The other chain I'm keeping an eye on is debian-installer, which seems to be waiting indirectly on php/apache. Ian. -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1400181653.15871.29.ca...@hastur.hellion.org.uk
Re: [Core] [Pkg-pascal-devel] arm64 update - help wanted
Am 15.05.2014 20:35, schrieb Abou Al Montacir: Hi All, On Thu, 2014-05-15 at 19:31 +0200, Paul Gevers wrote: [Dropping d-devel] On 15-05-14 03:10, Wookey wrote: Also if anyone has expertise in language porting we'd like to hear from you. Below is the list of languages we believe still need porting to arm64: Anyone who is interested in doing this work, or just has some idea of how much work is involved, do please pipe up (I don't know if each of these is 6 months or 6 minutes). There is a porter box available. Pascal We have a list for that. Abou, do you know the status of upstream support for arm64? Do you think it is worth it to try out building on the porter box? Do you have any idea what would be involved? As i can see in the makefile there is no arm64 in CPU_TARGET when grepping make files: [...] However I'm not sure and thus I'm cc-ing upstream for more accurate answer. FPC has no working aarch64/arm64 backend yet, so trying to build it makes currently no sense. There is a demand for it, see http://bugs.freepascal.org/view.php?id=25042 but no work happened within the last year. -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/53750ebf.8070...@freepascal.org
Re: arm64 update - help wanted
W dniu 15.05.2014 21:20, Ian Campbell pisze: On Thu, 2014-05-15 at 02:10 +0100, Wookey wrote: Also if anyone has expertise in language porting we'd like to hear from you. Below is the list of languages we believe still need porting to arm64: Ruby wasn't on the list, is that under control? Ruby is fine on AArch64 already. So is Perl, Python, OCaml. -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/53751953.4010...@juszkiewicz.com.pl
Re: arm64 update - help wanted
On Thu, 2014-05-15 at 21:45 +0200, Marcin Juszkiewicz wrote: W dniu 15.05.2014 21:20, Ian Campbell pisze: On Thu, 2014-05-15 at 02:10 +0100, Wookey wrote: Also if anyone has expertise in language porting we'd like to hear from you. Below is the list of languages we believe still need porting to arm64: Ruby wasn't on the list, is that under control? Ruby is fine on AArch64 already. http://buildd.debian-ports.org/status/package.php?p=ruby2.0suite=sid says it is BD-Uninstallable, due to build depending on ruby, so I presume there is still a bootstrapping issue. Ian. -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1400185772.15871.32.ca...@hastur.hellion.org.uk
Re: arm64 update - help wanted
W dniu 15.05.2014 22:29, Ian Campbell pisze: On Thu, 2014-05-15 at 21:45 +0200, Marcin Juszkiewicz wrote: W dniu 15.05.2014 21:20, Ian Campbell pisze: On Thu, 2014-05-15 at 02:10 +0100, Wookey wrote: Also if anyone has expertise in language porting we'd like to hear from you. Below is the list of languages we believe still need porting to arm64: Ruby wasn't on the list, is that under control? Ruby is fine on AArch64 already. http://buildd.debian-ports.org/status/package.php?p=ruby2.0suite=sid says it is BD-Uninstallable, due to build depending on ruby, so I presume there is still a bootstrapping issue. OK, I meant AArch64 in total, not in Debian (where I do not track status). -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/53752657.7040...@juszkiewicz.com.pl
Re: arm64 update - help wanted
Le jeudi 15 mai 2014 à 02:10 +0100, Wookey a écrit : Also if anyone has expertise in language porting we'd like to hear from you. Below is the list of languages we believe still need porting to arm64: Julia Note that currently Julia is only available on i386/amd64 (so no armel/armhf for the moment). But porting to ARM is being worked on upstream, and seems not to far away. It is tracked in this issue: https://github.com/JuliaLang/julia/issues/3134 -- .''`.Sébastien Villemot : :' :Debian Developer `. `' http://www.dynare.org/sebastien `- GPG Key: 4096R/381A7594 signature.asc Description: This is a digitally signed message part
Re: arm64 update - help wanted
On Thu, May 15, 2014 at 02:10:39AM +0100, Wookey wrote: GHCi (ghc is done, but not ghci - is this hard?) This is hard. You need either an LLVM-based port or a native code generator, and in either case I think you need some linker support in GHC. Both of these are serious compiler engineer projects. Fortunately these only block a minority of Haskell packages ... -- Colin Watson [cjwat...@debian.org] -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140516000230.ga13...@riva.ucam.org
Re: arm64 update - help wanted
On Thu, May 15, 2014 at 08:20:53PM +0100, Ian Campbell wrote: On Thu, 2014-05-15 at 02:10 +0100, Wookey wrote: Also if anyone has expertise in language porting we'd like to hear from you. Below is the list of languages we believe still need porting to arm64: Ruby wasn't on the list, is that under control? Ruby seems to be at the bottom of the build-dep chain for the kernel (linux-patchutils-rpm-libsemanage-ruby). The code is ported, but starting at 1.9 Ruby needs an existing Ruby interpreter to build. Ruby 1.8 needs only gcc-4.6 ... which needs patchutils. So we got ourselves a loop there. I have just committed a change to ruby that AFAICT will actually allow it to be built against ruby1.8 ( http://deb.li/nZlv ), any ideas on how to break the loop? -- Antonio Terceiro terce...@debian.org signature.asc Description: Digital signature
Re: arm64 update - help wanted
Antonio Terceiro wrote: The code is ported, but starting at 1.9 Ruby needs an existing Ruby interpreter to build. Ruby 1.8 needs only gcc-4.6 ... which needs patchutils. So we got ourselves a loop there. I would think that during bootstrapping core packages like gcc and patchutils would be crossbuilt. I would suspect that the reason gcc-4.6 is not available on arm64 is that noone has bothered to port a version of gcc that is now three releases behind current. I have just committed a change to ruby that AFAICT will actually allow it to be built against ruby1.8 ( http://deb.li/nZlv ), any ideas on how to break the loop I see a few possibilities 1: use the packages from ubuntu in your build environment. 2: crossbuild ruby (assuming that doing so is possible) 3: see if you can get ruby 1.8 to work with a recent gcc. For example you might want to see what happens if you build ruby 1.8 with a recent gcc and -O0 I'm ccing this to the removal bug for ruby 1.8 as if it is the only way to bootstrap then it might be a good idea to keep it arround. -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/53757b42.9070...@p10link.net
Re: arm64 update - help wanted
+++ peter green [2014-05-16 03:43 +0100]: Antonio Terceiro wrote: The code is ported, but starting at 1.9 Ruby needs an existing Ruby interpreter to build. Ruby 1.8 needs only gcc-4.6 ... which needs patchutils. So we got ourselves a loop there. I would think that during bootstrapping core packages like gcc and patchutils would be crossbuilt. I would suspect that the reason gcc-4.6 is not available on arm64 is that noone has bothered to port a version of gcc that is now three releases behind current. Correct. but in fact ruby1.8 builds fine with gcc-4.8. I just did it. Sadly this handy bootstrap route is going to go away in future and ruby will become yet another painful self-bootstraping language. I have just committed a change to ruby that AFAICT will actually allow it to be built against ruby1.8 ( http://deb.li/nZlv ), This will be very handy, as it avaids having to hack about with symlinks to get the effect of the ruby-defaults packages (which of course depend on the ruby2.1 I'm trying to build). 1: use the packages from ubuntu in your build environment. 2: crossbuild ruby (assuming that doing so is possible) In the long term I think this might be the best thing to get working. 3: see if you can get ruby 1.8 to work with a recent gcc. Done, but ruby1.8 is due to be removed from Debian so won't help in the future. I'm ccing this to the removal bug for ruby 1.8 as if it is the only way to bootstrap then it might be a good idea to keep it arround. That would be fine by me, but I'm guessing that at some point it will become too old to work for this? Wookey -- Principal hats: Linaro, Emdebian, Wookware, Balloonboard, ARM http://wookware.org/ -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140516032127.gy29...@stoneboat.aleph1.co.uk
Re: Shutdown button not working on LXDE environment
On Thu, May 15, 2014 at 8:05 PM, Divya Subramanian wrote: I checked it but no such packages are removed. Seems I was mistaken, I thought you were talking about a hardware button. Where does the shut down button from application menu mapsto ? That depends on the software in question. At a guess, lxpanel is package containing the shutdown button for LXDE. Looking at codesearch.d.n for lxpanel I found that shutdown in lxpanel uses gdm or hal. hal has been removed from Debian so I doubt you are using that. IIRC gdm requires systemd interfaces. Searching the Internet for systemd shutdown debian, I found some related links, including that this is a known bug. The issue is that the LXDE support for systemd/logind is buggy. Your options are to get an NMU of lxsession with the Maeiga/upstream patch included, get involved in the LXDE team and help them maintain it and fix the bug, switch back to sysvinit or ignore it for now and use systemctl poweroff/init 0/shutdown -h now. http://sources.debian.net/src/lxpanel/latest/debian/lxpanel.README.Debian https://bugs.debian.org/730123 https://bugs.debian.org/731489 BTW: LXDE will be probably soon be removed from Debian to make way for the rewrite called LXQt. -- bye, pabs http://wiki.debian.org/PaulWise -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CAKTje6F=d3bq4kfsh+lm6hmegrbsw5sx_vopbexdxstetik...@mail.gmail.com
