Re: [opensuse-arm] Please trigger rebuild of openSUSE:Factory:ARM ImageMagick
Le 04/02/2014 22:17, Dirk Müller a écrit : Hi *, Could you, trigger rebuild of openSUSE:Factory:ARM ImageMagick. done Normally those manual rebuilds should not be necessary, as I have a cron job running that does that. There was apparently an error around ImageMagick now, hopefully fixed. What is the advantage of your cron job vs an OBS auto trigger? Needed rebuild are triggered. No? yes at least direct dependencies. Is someone objecting in changing this? Well, at least for armv7l we don't have the build power in doing so, and since the rebuild script works just fine (normally), I didn't see the need for rebuilding with direct dependencies. With build-compare, there is no unneeded rebuilds, so it should be fine and would avoid some errors. Just my 2 cents. Guillaume -- To unsubscribe, e-mail: opensuse-arm+unsubscr...@opensuse.org To contact the owner, e-mail: opensuse-arm+ow...@opensuse.org
Re: [opensuse-arm] clamav not available on openSUSE 13.1 repository for armv6hl
Op dinsdag 4 februari 2014 14:35:06 schreef Freek de Kruijf: Op dinsdag 4 februari 2014 13:49:18 schreef Andreas Schwab: Freek de Kruijf fr...@opensuse.org writes: Please give me some hints, how to proceed and where and what to branch. Once you have branched it you can additional architectures to the project configuration in your branch. I want to build clamav for openSUSE 13.1, so should I branch openSUSE 13.1 / clamav? However there is no openSUSE:13.1:Update repository for armv6l to which I assume the result should be committed. This is because I am using the newest RaspberryPi image in a test Raspberry PI, which only has the openSUSE 13.1 oss repository. I could not find any additional repository. I played around on the OBS website branching security:clamav, but this one did not have a possibility to add the armv6l architecture. At least I could not find that possibility. I could find setting a repository to include armv6l, but I could not find a way to branch clamav into that repository. So I need some help to continue. -- fr.gr. member openSUSE Freek de Kruijf -- To unsubscribe, e-mail: opensuse-arm+unsubscr...@opensuse.org To contact the owner, e-mail: opensuse-arm+ow...@opensuse.org
Re: [opensuse-arm] clamav not available on openSUSE 13.1 repository for armv6hl
Freek de Kruijf fr...@opensuse.org writes: I played around on the OBS website branching security:clamav, but this one did not have a possibility to add the armv6l architecture. You'll need to add a new repository that points to openSUSE:Factory:ARM. For openSUSE:13.1:Update you are SOL, unfortunately, since it isn't set up to build for armv6l. Andreas. -- Andreas Schwab, SUSE Labs, sch...@suse.de GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7 And now for something completely different. -- To unsubscribe, e-mail: opensuse-arm+unsubscr...@opensuse.org To contact the owner, e-mail: opensuse-arm+ow...@opensuse.org
Re: [opensuse-arm] Please trigger rebuild of openSUSE:Factory:ARM ImageMagick
Hi Guillaume, What is the advantage of your cron job vs an OBS auto trigger? Needed rebuild are triggered. No? The direct rebuild flag works different from the cron job. The cron job rebuilds packages that became uninstallable. The direct rebuild rebuilds all direct dependencies of a changed package, which is usually significantly more. Furthermore it is the cron job is the same method that openSUSE Factory works. I agree with you that the uninstallable rebuild flag should be implemented in OBS, but it is not. With build-compare, there is no unneeded rebuilds, so it should be fine and would avoid some errors. build-compare is throwing away build results if they were determined to not matter. Which means the build power is already wasted. build-compare reduces download/update time for someone using zypper up / dup to keep his system fresh, it does not reduce the number of rebuilds in our local build mode. Greetings, Dirk -- To unsubscribe, e-mail: opensuse-arm+unsubscr...@opensuse.org To contact the owner, e-mail: opensuse-arm+ow...@opensuse.org
Re: [opensuse-arm] Please trigger rebuild of openSUSE:Factory:ARM ImageMagick
On Mittwoch, 5. Februar 2014, 12:34:40 wrote Dirk Müller: Hi Guillaume, What is the advantage of your cron job vs an OBS auto trigger? Needed rebuild are triggered. No? The direct rebuild flag works different from the cron job. The cron job rebuilds packages that became uninstallable. The direct rebuild rebuilds all direct dependencies of a changed package, which is usually significantly more. Furthermore it is the cron job is the same method that openSUSE Factory works. I agree with you that the uninstallable rebuild flag should be implemented in OBS, but it is not. With build-compare, there is no unneeded rebuilds, so it should be fine and would avoid some errors. build-compare is throwing away build results if they were determined to not matter. Which means the build power is already wasted. yes, but it reduces at least indirect builds. build-compare reduces download/update time for someone using zypper up / dup to keep his system fresh, it does not reduce the number of rebuilds in our local build mode. Greetings, Dirk -- Adrian Schroeter email: adr...@suse.de SUSE LINUX GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 21284 (AG Nürnberg) Maxfeldstraße 5 90409 Nürnberg Germany -- To unsubscribe, e-mail: opensuse-arm+unsubscr...@opensuse.org To contact the owner, e-mail: opensuse-arm+ow...@opensuse.org
[opensuse-arm] Latest Chromebook images
Hi, are the latest Chromebook images supposed to work? I tried the most recent Factory-ARM-XFCE-chromebook.armv7l-1.12.1-Build169.2 (of today) and got - ** File not found uEnv.txt Loading file boot.scr from mmc device 1:2 (lxboot) 2138 bytes read Running bootscript ... ## Executing script at 40007000 mmc_init err 0, time 101923 mmc0(part 0) is current deuice Loading file boot/linux.vmx from mmc deuice 0:2 (KERN-A) Failed to mount ext2 filesystem ... ** Bad ext2 partition or disk — mmc 0:2 ** mmc1 is current device Loading file boot/linux.vmx from mmc device 1:2 (lxboot) 3568304 bytes read Loading file boot/initrd.uboot from mmc device 1:2 (lxboot) ** ext2fs doesn't support tripple indirect blocks. ** ** Unable to read boot/initrd.uboot from mmc 1:2 ** Loading file dtb/exynos5250—snow.dtb from mmc device 1:2 (lxboot) 34150 bytes read ## Booting kernel from Legacy Image at 40007000 ... Image Name: Linux—3.4.0—2—chromebook Image Type: ARM Linux Kernel Image (uncompressed) Data Size: 3568240 Bytes = 3.4 MiB Load address: 40008000 Entry Point: 40008000 Verifying Checksum ... OK ## Loading init Ramdisk from Legacy Image at 4f00 ... Image Name: Initrd Image Type: ARM Linux RAMDisk Image (uncompressed) Data Size: 156490936 Bytes = 149.2 MiB Load Address: Entry Point: Verifying Checksum ... Bad Data CRC Ramdisk image is corrupt or invalid mmc0(part 0) is current device ** Block device usb 0 not supported mmc1 is current device ** Block device usb 1 not supported (Re)start USB... USB: Register 1313 NbrPorts 3 [USB] usb_lowlevel_init:852 0 [USB] usb_lowlevel_init:852 1 USB EHCI 1.00 1 USB Device(s) found scanning bus for storage devices ... 0 Storage Device(s) found Tring USB on device ** Block device usb 0 not supported ** Block device usb 0 not supported SMDK5250 # - on initial boot. Same result with most recent 13.1 images. Best regards, --D.B. -- Daniel Bischof suse-b...@bischof.org
[opensuse-arm] Re: Re : [opensuse-arm] Latest Chromebook images
Hi, I was trying something different to get the chromebook working: I found in the Images.wiwi.in, that a lot of packages are marked as PKG_BOOT_TAG and that way included in the initrd, suchas vboot, gptfdisk,mrvl-firmware, which shouldnt be needed for booting imo. I reduced those to just PKG_BOOT_TAG(u-boot-chromebook), PKG_BOOT_TAG(dtb-exynos5), which resulted in a smaller initrd that loaded without warnings. But then I get just a black screen after the kernel is (hopefully) started. In my opinion, this initrd is far too huge anyway, and I wonder why that is. Josua Mayer Am 05.02.2014 20:46, schrieb guillaume.gar...@free.fr: Hi, - Daniel Bischof suse-b...@bischof.org a écrit : Hi, are the latest Chromebook images supposed to work? I tried the most recent Factory-ARM-XFCE-chromebook.armv7l-1.12.1-Build169.2 (of today) and got No. The problem is ext2fs doesn't support tripple indirect blocks which prevent to load all the initrd. I am working on upstream u-boot which could fix that. But it is not yet ready. :( Guillaume - ** File not found uEnv.txt Loading file boot.scr from mmc device 1:2 (lxboot) 2138 bytes read Running bootscript ... ## Executing script at 40007000 mmc_init err 0, time 101923 mmc0(part 0) is current deuice Loading file boot/linux.vmx from mmc deuice 0:2 (KERN-A) Failed to mount ext2 filesystem ... ** Bad ext2 partition or disk — mmc 0:2 ** mmc1 is current device Loading file boot/linux.vmx from mmc device 1:2 (lxboot) 3568304 bytes read Loading file boot/initrd.uboot from mmc device 1:2 (lxboot) ** ext2fs doesn't support tripple indirect blocks. ** ** Unable to read boot/initrd.uboot from mmc 1:2 ** Loading file dtb/exynos5250—snow.dtb from mmc device 1:2 (lxboot) 34150 bytes read ## Booting kernel from Legacy Image at 40007000 ... Image Name: Linux—3.4.0—2—chromebook Image Type: ARM Linux Kernel Image (uncompressed) Data Size: 3568240 Bytes = 3.4 MiB Load address: 40008000 Entry Point: 40008000 Verifying Checksum ... OK ## Loading init Ramdisk from Legacy Image at 4f00 ... Image Name: Initrd Image Type: ARM Linux RAMDisk Image (uncompressed) Data Size: 156490936 Bytes = 149.2 MiB Load Address: Entry Point: Verifying Checksum ... Bad Data CRC Ramdisk image is corrupt or invalid mmc0(part 0) is current device ** Block device usb 0 not supported mmc1 is current device ** Block device usb 1 not supported (Re)start USB... USB: Register 1313 NbrPorts 3 [USB] usb_lowlevel_init:852 0 [USB] usb_lowlevel_init:852 1 USB EHCI 1.00 1 USB Device(s) found scanning bus for storage devices ... 0 Storage Device(s) found Tring USB on device ** Block device usb 0 not supported ** Block device usb 0 not supported SMDK5250 # - on initial boot. Same result with most recent 13.1 images. Best regards, --D.B. -- Daniel Bischof suse-b...@bischof.org -- To unsubscribe, e-mail: opensuse-arm+unsubscr...@opensuse.org To contact the owner, e-mail: opensuse-arm+ow...@opensuse.org
