Re: [Mageia-dev] [changelog] [RPM] cauldron core/release libvirt-1.0.2-4.mga3
Op maandag 1 april 2013 08:38:43 schreef Mustafa Muhammad: On Mar 31, 2013 10:19 PM, AL13N al...@rmail.be wrote: Op zondag 31 maart 2013 00:52:08 schreef Thierry Vignaud: On 31 March 2013 00:48, Thierry Vignaud thierry.vign...@gmail.com wrote: On 8 March 2013 07:54, AL13N al...@rmail.be wrote: Mar 08 07:12:59 localhost libvirtd[860]: Unable to issue hypervisor ioctl 3166208: Permission non accordée I applied a patch from FC that fixed the ioctl errors BTW all FC patches seems to have been mergd in libvirt-1.0.3 See http://libvirt.org/news.html for changelog i have been testing libvirt-1.0.3 locally, due to a bug that kills libvirtd when a domain has been shut down... unfortunately, it doesn't fix it... i'm trying to follow up with upstream to get this fixed... i hope i make it in time... Then I hope you push 1.0.4 as it out today. is it? or is this an april fools joke? i'm gonna check it out, since i haven't heard of the libvirt persons who would check out my bug...
Re: [Mageia-dev] [changelog] [RPM] cauldron core/release libvirt-1.0.2-4.mga3
Op zondag 31 maart 2013 00:52:08 schreef Thierry Vignaud: On 31 March 2013 00:48, Thierry Vignaud thierry.vign...@gmail.com wrote: On 8 March 2013 07:54, AL13N al...@rmail.be wrote: Mar 08 07:12:59 localhost libvirtd[860]: Unable to issue hypervisor ioctl 3166208: Permission non accordée I applied a patch from FC that fixed the ioctl errors BTW all FC patches seems to have been mergd in libvirt-1.0.3 See http://libvirt.org/news.html for changelog i have been testing libvirt-1.0.3 locally, due to a bug that kills libvirtd when a domain has been shut down... unfortunately, it doesn't fix it... i'm trying to follow up with upstream to get this fixed... i hope i make it in time...
Re: [Mageia-dev] freeze push: ldetect, drakx-installer-binaries, drakx-installer-stage2, drakx-installer-images
Op zondag 31 maart 2013 00:36:47 schreef Thierry Vignaud: Hi Please let in ldetect, drakx-installer-binaries, drakx-installer-stage2 drakx-installer-images. They bring support for installing on Xen (PV). - ldetect: add support for detecting Xen blk net controllers (mga#9546) Once it's available, please submit: - drakx-installer-binaries: probe virtual drivers too (mga#9546) (install from Xen hd not supported yet but fetching installer from HD is not that usefull when virtualized) - drakx-installer-stage2: fix detecting Xen hard disks (mga#9546) Once drakx-installer-binaries is available, please submit drakx-installer-images (both to core/release and to nonfree-release): it'll include new stage1 binary in stage1 (boot.iso and all.rdz) so that we support installing on Xen. Tested on Xen paravirtualising on legacy (no KVM support) HW. Thx that's just awesome work! i'm gonna test this on HVM-PV
Re: [Mageia-dev] Apache doesn't always like restarting....
Op woensdag 27 maart 2013 23:12:13 schreef Colin Guthrie: [...] Are you absolutely sure it's not just apache resetting the value when you don't set CoreDumpDirectory in your httpd.conf? for me it was with libvirtd and on x86_64 setting coreLIMIT=infinity, made it a soft limit to 0; and hard to unlimited, setting it to a lower value worked for me. perhaps it was libvirtd doing this itself... allthough that seems farfetched... it seemed more likely that setting max number was somehow broken in systemd or below... moreover, the systemd is compiled without coredump functionality, and that seems to have an effect on this and disallows one to configure systemd-coredump (which isn't build nor packaged) for usage with integrated coredumps with the systemd-coredump-ctl executable, (which is packaged). This was a deliberate decision at the time. There were not sufficient tools to extract coredumps from the journal logs and really the coredump support should be separate from the coredump capturing and logging to the journal anyway, so it shouldn't affect anything you're doing right now (e.g. it shouldn't affect how you setup apache) ok, but you can package it and not set it to be used... The fact that systemd-coredump-ctl is build is IMO a bug, and one that could very well be fixed upstream already (probably is) but I didn't want to keep the rm in the %install section of the spec lest it was accidentally left in there when we turn the feature on (when it's generally more useful - i.e. you can store cores in a directory outside of the journal etc etc.). perhaps it wouldn't get left as you would have an additional executable, so you'd have to change the file sections anyway... [...] As for the core dump support, I would be happy enough re-enabling it again. I'm just not convinced that storing the dumps in the journal is a great idea. I mean if you get a constantly crashing service, your logs will fill up quickly and be rotated away quickly. I think the cores should be stored outside of the journal. I can't remember off hand if the patch that implemented this was finally committed or not - I'll have a look and check. i'm not saying it should be set as default, but if you have systemd-coredump- ctl i think you should also have systemd-coredump ... and why not provide the service if people want to use it, as long as you don't set the /proc thing, it doesn't get used, so...
Re: [Mageia-dev] mageia 3 beta 4 installer infinitely slow?
Op woensdag 27 maart 2013 08:10:18 schreef Eatdirt: Hi, just tested a boot.iso with network upgrade from mga2-mga3. That's completely unusable even on a 10Mb connection. It announces more than 10h of upgrade even by selecting the minimal number of media (core release only). Playing with the CTRL+ALT+Fx, the packages are downloaded fast (up to 10Mb/s) but the installer looses *a lot* of time doing this: workaround bug in rpmlib by removing /var/lib/rpm/__db* is that pb fixed already or shall I open a bug report? Cheers, chris, better to have a bug and mark it release critical
Re: [Mageia-dev] Apache doesn't always like restarting....
Hiya, Not sure if others ever get this but sometimes my apache really doesn't like being restarted. Looking at things when it's in this stuck state it appears to be waiting on a mutex: Process 24205 attached futex(0x7fde0090c640, FUTEX_WAIT_PRIVATE, 2, NULL unfinished ... Eventually systemd gets tired waiting and kills it properly +++ killed by SIGKILL +++ which is nice from a cleanliness perspective - I'm pretty sure that before either sysvinit would have just hung or returned from the stop job without killing things properly and then started apache again and gotten then failed to bind to port 80 type error I'm sure I remember seeing. Anyway, don't think this is something we can easily fix just now and it's quite sporadic (doesn't always happen). One of these days I'll be able to attach to it properly and get a nice backtrace :) this reminds me... you should try to fix the dumping of core via systemd. the other day i tried to get cores, but somehow unlimited meant 0 meant no core at all #systemd people told me that my distro's systemd isn't built with the coredump option, which may refuse to dump cores in services.
Re: [Mageia-dev] Apache doesn't always like restarting....
Op woensdag 27 maart 2013 15:44:48 schreef Guillaume Rousse: Le 27/03/2013 15:09, AL13N a écrit : the other day i tried to get cores, but somehow unlimited meant 0 meant no core at all You need to set LimitCORE=infinity in unit file, according to systemd.exec man page. And you probably need the adequate sysctl setting (kernel.core_pattern) to ensure the core file get dumped into a predictible directory. actually, no, setting LimitCORE=infinity (also our default as shown with systemctl show *.service) ends up with the actual limit being 0 as shown by prlimit. (this was with help from #systemd people) moreover, the systemd is compiled without coredump functionality, and that seems to have an effect on this and disallows one to configure systemd-coredump (which isn't build nor packaged) for usage with integrated coredumps with the systemd-coredump-ctl executable, (which is packaged). @colin, so please, fix these 2 issues (first one looks like a systemd issue; while the second one is a packaging issue)
Re: [Mageia-dev] Packages not rebuilt since Mageia 2
Op woensdag 27 maart 2013 19:47:12 schreef Guillaume Rousse: [...] no offense meant, and the time you spend fixing these are very much appreciated, but if tests fail, perhaps we should just drop these instead of having them?
Re: [Mageia-dev] USB Keyboard disabled in current stage1
Op dinsdag 26 maart 2013 18:35:00 schreef Thierry Vignaud: On 23 March 2013 13:31, Thierry Vignaud thierry.vign...@gmail.com wrote: @thierry: i donno what you think of it, but imo: A) fixing lstdetect would be the cleanest way (maybe not the simplest) B) perhaps in the comparing i can workaround this, but the compare code will not be as simple as it should... forgot to mention option C: C) using kmod in stage1 but option C might not be as easy and will increase the stage1 size; and raises the question if stage2 is actually still needed then...? As already said, stage1 uses ldetect which use libkmod, thus we already are linked to it. mdv switched to kmod. You can look at it. But show me the patch before commiting it. In the meantime please upload a stage1 with your change revertd yeah, this might be over my head as a beginner in this kind of code... I was hoping a simple workaround would do for now, since we're already this late... but i guess since we're linking into libkmod anyway, it might as well be done. i'm not confident, but i'll give it a try. I've backported the needed changes. I've tested it with USB hid, it worked. Please test too (normal modules + xen). Then I'll submit it Ping? Can you test it? ah, sorry, all modules seem to load fine, i tested with several modules, no failed modules, including xen modules that effectively solves this problem.
Re: [Mageia-dev] drakxtools drakx-installer-stage2 (mga#9428)
Op vrijdag 22 maart 2013 07:38:56 schreef Frank Griffin: On 03/22/2013 07:20 AM, Glen Ogilvie wrote: [...] 1. How does the src tar.xz file for drakx-installer-stage2 get created? I assume it comes from a build of svn://svn.mageia.org/svn/soft/drakx/trunk http://svn.mageia.org/svn/soft/drakx/trunk, but can't find how it ends up as a tar.xz I'm maybe about two days ahead of you on this, but here's what I think happens, FWIW. You do your checkout, and then in the mdk-stage1 subdirectory, do a make dist-svn. This should produce the tar.xz in the mdk-stage1 directory. [...] make dist actually... it will target make dist-svn or make dist-git depending on if you're using git-svn or not. be advised that dist-svn uses the BASE and any uncommitted change will not be applied. dist-git however, you can commit without pushing them and that will be used.
Re: [Mageia-dev] freeze push: urpmi rpmdrake
Op donderdag 21 maart 2013 08:41:32 schreef Thierry Vignaud: Hi Please let in urpmi rpmdrake. Both test testsuites pass. urpmi fixes main_window management for rpmdrake rpmdrake is fixed regarding download progress bar. It also now uses the global progress bar for downloads too. thx whoa, that is nice!
Re: [Mageia-dev] USB Keyboard disabled in current stage1
Op dinsdag 19 maart 2013 18:53:07 schreef Frank Griffin: On 03/19/2013 04:56 PM, AL13N wrote: a module list of loaded modules with that hardware... i think it might be this commit, but i'm wondering what's the difference inbetween automatic loading and loading from the module box. iow: we need to find what module is actually the problem Here we go ... [root@ftgfw ftg]# lsmod Module Size Used by ipcomp 12661 0 xfrm_ipcomp13413 1 ipcomp ah413044 0 esp4 17098 0 deflate12617 0 ctr13005 0 twofish_generic16635 0 twofish_x86_64_3way27181 0 twofish_x86_64 12907 1 twofish_x86_64_3way twofish_common 21113 3 twofish_generic,twofish_x86_64_3way,twofish_x86_64 camellia_generic 29260 0 camellia_x86_6453205 0 serpent_sse2_x86_6450443 0 serpent_generic25727 1 serpent_sse2_x86_64 xts12914 3 camellia_x86_64,serpent_sse2_x86_64,twofish_x86_64_3way lrw13286 3 camellia_x86_64,serpent_sse2_x86_64,twofish_x86_64_3way gf128mul 14951 2 lrw,xts glue_helper13541 3 camellia_x86_64,serpent_sse2_x86_64,twofish_x86_64_3way blowfish_generic 12530 0 blowfish_x86_6421381 0 blowfish_common16739 2 blowfish_generic,blowfish_x86_64 cast5_generic 21429 0 cast_common12983 1 cast5_generic ablk_helper13597 1 serpent_sse2_x86_64 cryptd 20403 1 ablk_helper des_generic21350 0 cbc12774 0 xcbc 12815 0 rmd160 16744 0 sha512_generic 12770 0 sha256_generic 21005 0 sha1_generic 12845 0 crypto_null12840 0 af_key 36092 2 xfrm_algo 15508 4 ah4,esp4,af_key,xfrm_ipcomp fuse 78830 2 ipt_IFWLOG 12622 2 ipt_psd57587 1 cls_basic 12946 0 cls_flow 17125 0 cls_fw 12904 0 cls_u3217137 0 sch_tbf13064 0 sch_prio 13152 0 sch_htb22146 0 sch_hfsc 22206 0 sch_ingress12866 0 sch_sfq21375 0 bridge100378 0 stp12976 1 bridge llc14552 2 stp,bridge xt_CHECKSUM12549 0 ipt_rpfilter 12546 0 xt_statistic 12601 0 xt_CT 12868 18 xt_LOG 17521 8 xt_time12661 0 xt_connlimit 12636 0 xt_realm 12498 0 xt_addrtype12635 4 ip_set_hash_ip 32055 2 xt_comment 12504 18 xt_recent 18542 0 xt_policy 12582 20 xt_nat 12681 0 ipt_ULOG 18245 0 ipt_REJECT 12541 4 ipt_MASQUERADE 12880 1 ipt_ECN12529 0 ipt_CLUSTERIP 13508 0 ipt_ah 12806 0 xt_set 13099 2 ip_set 36382 2 ip_set_hash_ip,xt_set nf_nat_tftp12489 0 nf_nat_snmp_basic 17302 0 nf_conntrack_snmp 12857 3 nf_nat_snmp_basic nf_nat_sip 17152 0 nf_nat_pptp13115 0 nf_nat_proto_gre 13009 1 nf_nat_pptp nf_nat_irc 12643 0 nf_nat_h32317720 0 nf_nat_ftp 12770 0 nf_nat_amanda 12491 0 ts_kmp 12605 5 nf_conntrack_amanda13041 3 nf_nat_amanda nf_conntrack_sane 13143 2 nf_conntrack_tftp 13121 3 nf_nat_tftp nf_conntrack_sip 29771 3 nf_nat_sip nf_conntrack_proto_udplite13281 0 nf_conntrack_proto_sctp18822 0 nf_conntrack_pptp 19245 3 nf_nat_pptp nf_conntrack_proto_gre14434 1 nf_conntrack_pptp nf_conntrack_netlink35735 0 nf_conntrack_netbios_ns12665 2 nf_conntrack_broadcast12589 2 nf_conntrack_netbios_ns,nf_conntrack_snmp nf_conntrack_irc 13518 3 nf_nat_irc nf_conntrack_h323 73845 1 nf_nat_h323 nf_conntrack_ftp 18643 3 nf_nat_ftp xt_TPROXY 17327 0 nf_defrag_ipv6 18261 1 xt_TPROXY nf_tproxy_core 12610 1 xt_TPROXY xt_tcpmss 12501 0 xt_pkttype 12504 0 xt_physdev 12587 0 xt_owner 12534 0 xt_NFQUEUE 12694 0 xt_NFLOG 12537 0 nfnetlink_log 17798 1 xt_NFLOG xt_multiport 12798 4 xt_mark12563 1 xt_mac 12492 0 xt_limit 12711 0 xt_length 12536 0 xt_iprange 12783 0 xt_helper 12583 0 xt_hashlimit 17569 0 xt_DSCP12629 6 xt_dscp12597 0 xt_dccp
Re: [Mageia-dev] USB Keyboard disabled in current stage1
Op woensdag 20 maart 2013 12:50:06 schreef Frank Griffin: On 03/20/2013 12:34 PM, Frank Griffin wrote: I'm confused. I see your point: modules.dep and the actual driver module filenames in /lib/modules use dashes in the names, while usbtable uses underscores. So why does lsmod show underscores instead of dashes ? Also, why do the two differ ? If the kernel package, which one would think is definitive, uses dashes, why does ldetect-lst use underscores ? Oh, one other thing. On the working system, harddrake shows two keyboard devices: a USB keyboard (PCI 0x1226/0x0034) and a LiteON USB Keyboard (PCI 0x04ca/0x0022). Neither of these appear in usbtable. Or is the problem with *any* USB device because of the ehci-*** modules that are needed ? 1. since ages already, modprobe accepts with - or with _ it makes no difference, 2. lsmod will always show _. 3. lstdetect (used in stage1) uses _ only. 4. stage1 manual module uses it based on filename/modules.dep, so it keeps original - or _ == this is what i'll write a patch for. to convert in table before displaying manual check. then, i'll also try to write a detect XenDevices procedure (like the virtIO that i've seen).
Re: [Mageia-dev] USB Keyboard disabled in current stage1
Op woensdag 20 maart 2013 15:50:06 schreef Frank Griffin: On 03/20/2013 01:33 PM, Thierry Vignaud wrote: That's because modules.alias enables to match through wildchars. eg for ehci (see either /sbin/modinfo ehci_pci or fgrep ehci /lib/modules/3.8.3-desktop-2.mga3/modules.alias): alias pci:v104AdCC00sv*sd*bc*sc*i* ehci_pci alias pci:v*d*sv*sd*bc0Csc03i20* ehci_pci That means that ehci matches both: - 0x104A 0xCC00 (probably a device that reports a broken/bogus class) - any PCI device whose class is PCI_CLASS_SERIAL_USB_EHCI Note that for this one: - lsmod reports ehci_pci - modinfo reports the real fs path: ehci-pci - lspci -vvk reports: ehci-pci I understand. It is the kernel itself (and associated tools) that mix and match underscore and dash. Hence the need for a conversion patch. not really, it just means that in the kernel - are mapped to _; modprobe tools handle both cases, just modinfo reports the filename which can include '-', but it can still handle both. lspci and most tools just report it as it's really named (depending on filename). modules.dep and modules.descr, etc... has the name as it is as well, meaning there can be '-' in the name. i just see this workaround being effective to handle lstdetect, which somehow forces all of it being lowercase... i don't know how much of lstdetect is hardcoded and how much of it is generated, but imho the cleanest way would be to fix lstdetect, so that it gives the proper module names... i've been looking at a way to fix the module list window for choosing, but the problem isn't as simple as i thought, since insmod looks at filenames... which is another workaround. @thierry: i donno what you think of it, but imo: A) fixing lstdetect would be the cleanest way (maybe not the simplest) B) perhaps in the comparing i can workaround this, but the compare code will not be as simple as it should...
Re: [Mageia-dev] USB Keyboard disabled in current stage1
Op woensdag 20 maart 2013 21:20:14 schreef AL13N: Op woensdag 20 maart 2013 15:50:06 schreef Frank Griffin: On 03/20/2013 01:33 PM, Thierry Vignaud wrote: That's because modules.alias enables to match through wildchars. eg for ehci (see either /sbin/modinfo ehci_pci or fgrep ehci /lib/modules/3.8.3-desktop-2.mga3/modules.alias): alias pci:v104AdCC00sv*sd*bc*sc*i* ehci_pci alias pci:v*d*sv*sd*bc0Csc03i20* ehci_pci That means that ehci matches both: - 0x104A 0xCC00 (probably a device that reports a broken/bogus class) - any PCI device whose class is PCI_CLASS_SERIAL_USB_EHCI Note that for this one: - lsmod reports ehci_pci - modinfo reports the real fs path: ehci-pci - lspci -vvk reports: ehci-pci I understand. It is the kernel itself (and associated tools) that mix and match underscore and dash. Hence the need for a conversion patch. not really, it just means that in the kernel - are mapped to _; modprobe tools handle both cases, just modinfo reports the filename which can include '-', but it can still handle both. lspci and most tools just report it as it's really named (depending on filename). modules.dep and modules.descr, etc... has the name as it is as well, meaning there can be '-' in the name. i just see this workaround being effective to handle lstdetect, which somehow forces all of it being lowercase... i don't know how much of lstdetect is hardcoded and how much of it is generated, but imho the cleanest way would be to fix lstdetect, so that it gives the proper module names... i've been looking at a way to fix the module list window for choosing, but the problem isn't as simple as i thought, since insmod looks at filenames... which is another workaround. @thierry: i donno what you think of it, but imo: A) fixing lstdetect would be the cleanest way (maybe not the simplest) B) perhaps in the comparing i can workaround this, but the compare code will not be as simple as it should... forgot to mention option C: C) using kmod in stage1 but option C might not be as easy and will increase the stage1 size; and raises the question if stage2 is actually still needed then...?
Re: [Mageia-dev] USB Keyboard disabled in current stage1
Op woensdag 20 maart 2013 21:21:35 schreef Thierry Vignaud: On 20 March 2013 20:47, AL13N al...@rmail.be wrote: I see your point: modules.dep and the actual driver module filenames in /lib/modules use dashes in the names, while usbtable uses underscores. So why does lsmod show underscores instead of dashes ? Also, why do the two differ ? If the kernel package, which one would think is definitive, uses dashes, why does ldetect-lst use underscores ? Oh, one other thing. On the working system, harddrake shows two keyboard devices: a USB keyboard (PCI 0x1226/0x0034) and a LiteON USB Keyboard (PCI 0x04ca/0x0022). Neither of these appear in usbtable. Or is the problem with *any* USB device because of the ehci-*** modules that are needed ? 1. since ages already, modprobe accepts with - or with _ it makes no difference, You know we don't use modprobe in stage1, do you? yes, i know... :-)
Re: [Mageia-dev] USB Keyboard disabled in current stage1
Op woensdag 20 maart 2013 21:28:51 schreef Thierry Vignaud: On 20 March 2013 21:22, AL13N al...@rmail.be wrote: That's because modules.alias enables to match through wildchars. eg for ehci (see either /sbin/modinfo ehci_pci or fgrep ehci /lib/modules/3.8.3-desktop-2.mga3/modules.alias): alias pci:v104AdCC00sv*sd*bc*sc*i* ehci_pci alias pci:v*d*sv*sd*bc0Csc03i20* ehci_pci That means that ehci matches both: - 0x104A 0xCC00 (probably a device that reports a broken/bogus class) - any PCI device whose class is PCI_CLASS_SERIAL_USB_EHCI Note that for this one: - lsmod reports ehci_pci - modinfo reports the real fs path: ehci-pci - lspci -vvk reports: ehci-pci I understand. It is the kernel itself (and associated tools) that mix and match underscore and dash. Hence the need for a conversion patch. not really, it just means that in the kernel - are mapped to _; modprobe tools handle both cases, just modinfo reports the filename which can include '-', but it can still handle both. lspci and most tools just report it as it's really named (depending on filename). modules.dep and modules.descr, etc... has the name as it is as well, meaning there can be '-' in the name. i just see this workaround being effective to handle lstdetect, which somehow forces all of it being lowercase... i don't know how much of lstdetect is hardcoded and how much of it is generated, but imho the cleanest way would be to fix lstdetect, so that it gives the proper module names... i've been looking at a way to fix the module list window for choosing, but the problem isn't as simple as i thought, since insmod looks at filenames... which is another workaround. @thierry: i donno what you think of it, but imo: A) fixing lstdetect would be the cleanest way (maybe not the simplest) B) perhaps in the comparing i can workaround this, but the compare code will not be as simple as it should... forgot to mention option C: C) using kmod in stage1 but option C might not be as easy and will increase the stage1 size; and raises the question if stage2 is actually still needed then...? As already said, stage1 uses ldetect which use libkmod, thus we already are linked to it. mdv switched to kmod. You can look at it. But show me the patch before commiting it. In the meantime please upload a stage1 with your change revertd yeah, this might be over my head as a beginner in this kind of code... I was hoping a simple workaround would do for now, since we're already this late... but i guess since we're linking into libkmod anyway, it might as well be done. i'm not confident, but i'll give it a try. PS: i commited the revert.
Re: [Mageia-dev] USB Keyboard disabled in current stage1
Op dinsdag 19 maart 2013 14:33:30 schreef Frank Griffin: On 03/19/2013 12:15 PM, Colin Guthrie wrote: 'Twas brillig, and Frank Griffin at 19/03/13 15:25 did gyre and gimble: Problem still present in last night's installer upload... Were you able to try Thierry's suggestion? My apologies, I must have missed it. I looked it up in the archives, and from the code involved, it looked like a good possibility. I went and read bug#9242, but given the trouble al13n had, I don't think I'd fare too well trying to check out and rebuild stage1. I've used svn lightly, years ago, but I'm not familiar with the MGA SVN layout at all. The dracut patch you mentioned added ehci-pci and ehci-platform. I drilled down into the all.rdz files for isolinux, and boot.iso, and all.rdz.uncompressed has all three of them (-hcd, -pci, -platform). The working cauldron partition from Mar 11's MCC harddrake reports the module for the USB keyboard as usbhid, which is there as well in all of them. So perhaps the problem is in some control list of things to be loaded ? If you can point me to that, I'll check it. I don't see any significant changes: http://svnweb.mageia.org/soft/drakx/trunk/mdk-stage1/?view=log So it would still be interesting to know if the commit he mentioned (http://svnweb.mageia.org/soft?view=revisionsortby=daterevision=7542) is the one to blame for this. My impression from the code and the bug report comments is that the change either converts - in module names to _ or vice-versa, or stops whichever of these it was doing before. Also, the bugreports states that tv is OK with this provided it's tested, and follows this up with I couldn't test it, so it's unclear what the status of the change really is. the patch removes the previous workaround that converts - in module filenames, to _ . it's removed because if a module is selected manually, it's made from filenames. so the - must match. maybe if a module isn't selected manually, it comes from lstdetect or udev or whatever it comes from... maybe your module is wrong... like that the modules are called ehci-hcd and the filename is called ehci_hcd ? it would be nice to know... if you can find a working setup (older livecd) and give an lsmod, we might be able to deduce that. from whatever modules you need. in any case, with this hardware, did the previous beta work?
Re: [Mageia-dev] USB Keyboard disabled in current stage1
Op dinsdag 19 maart 2013 16:53:46 schreef Frank Griffin: On 03/19/2013 03:35 PM, AL13N wrote: the patch removes the previous workaround that converts - in module filenames, to _ . it's removed because if a module is selected manually, it's made from filenames. so the - must match. maybe if a module isn't selected manually, it comes from lstdetect or udev or whatever it comes from... maybe your module is wrong... like that the modules are called ehci-hcd and the filename is called ehci_hcd ? it would be nice to know... if you can find a working setup (older livecd) and give an lsmod, we might be able to deduce that. from whatever modules you need. in any case, with this hardware, did the previous beta work? Well, I don't really test from the ISOs; I just build straight from cauldron. It did work on the same box on Mar 11, and I have that working system with its initrd and kernel module directories. But I'm not very familiar with the internal metadata lists we keep that would have to match up. If you can tell me precisely what you need and where to find it, I'll be happy to dig it out. a module list of loaded modules with that hardware... i think it might be this commit, but i'm wondering what's the difference inbetween automatic loading and loading from the module box. iow: we need to find what module is actually the problem
Re: [Mageia-dev] [soft-commits] [7542] - fix loading modules with - in their names (mga#9242)
Op donderdag 14 maart 2013 21:25:15 schreef Thierry Vignaud: On 14 March 2013 20:29, AL13N al...@rmail.be wrote: - fix loading modules with - in their names (mga#9242) - add an easy buildtarget for testing A couple remarks: - next time do a commit a time (first your change, then bumping version) ah, ok, is there a reason for this (to have separate a change and then a version bump)? in order to have smaller easier to review commits. You really do not want to come on big old commits when trying to understand a problem. I hope you tested several modules with both case? yes, i tried with several. and since the xen-netfront modules aren't autodetected for some reason (i'm trying to look into it) b/c it has no pci/usb alias, only the following (which we do not look for) alias: xennet alias: xen:vif well, we don't know how to detect that. supposedly udev should give events to load that... but perhaps stage1 doesn't use udev? would you think it would be ok, to manually add such workaround code in stage1?
Re: [Mageia-dev] [soft-commits] [7542] - fix loading modules with - in their names (mga#9242)
'Twas brillig, and AL13N at 15/03/13 06:50 did gyre and gimble: Op donderdag 14 maart 2013 21:25:15 schreef Thierry Vignaud: On 14 March 2013 20:29, AL13N al...@rmail.be wrote: - fix loading modules with - in their names (mga#9242) - add an easy buildtarget for testing A couple remarks: - next time do a commit a time (first your change, then bumping version) ah, ok, is there a reason for this (to have separate a change and then a version bump)? in order to have smaller easier to review commits. You really do not want to come on big old commits when trying to understand a problem. I hope you tested several modules with both case? yes, i tried with several. and since the xen-netfront modules aren't autodetected for some reason (i'm trying to look into it) b/c it has no pci/usb alias, only the following (which we do not look for) alias: xennet alias: xen:vif well, we don't know how to detect that. supposedly udev should give events to load that... but perhaps stage1 doesn't use udev? would you think it would be ok, to manually add such workaround code in stage1? For mga4 I hope I have the time to look into rebasing stage1 on dracut... not sure it is the right thing overall, but it would be nice to cut down on different things used in different places (assuming it doesn't cause any problems!). But, meh, we'll see how the time goes!! i doubt you'll have time... but, in that case, maybe stage1 (or stage2) is not required anymore??? maybe i should first do these workarounds about xen:vif ...
Re: [Mageia-dev] Release critical bugs for Mageia 3
Op vrijdag 15 maart 2013 17:02:47 schreef Johnny A. Solbu: On Friday 15. March 2013 15.26, Anne Nicolas wrote: So here is a review of these bugs: https://docs.google.com/spreadsheet/ccc?key=0Ao3phYOTRNeQdEEtSjBSSWkxTmdIc mJZcGtfYjN1NVEusp=sharing Really!? So now we need to register at Google in order to help develop Mageia? (I'm asked to login in order to see it) What's wrong with the wiki, a html file or a plain old text file? this is called bikeshedding... what's important here is that the bugs are fixed, and i'm sure you can find them using bugzilla anyway...
Re: [Mageia-dev] freeze push: drakx-installer-binaries
Op woensdag 13 maart 2013 21:00:45 schreef AL13N: Please push: drakx-installer-binaries: - fix loading modules with - in their names (mga#9242) in the stage1 window to load extra modules (eg: xen-netfront), all modules with '-' in the name failed. this fix allows those modules to be loaded when requested. ping
Re: [Mageia-dev] freeze push: drakx-installer-binaries
AL13N skrev 14.3.2013 08:38: Op woensdag 13 maart 2013 21:00:45 schreef AL13N: Please push: drakx-installer-binaries: - fix loading modules with - in their names (mga#9242) in the stage1 window to load extra modules (eg: xen-netfront), all modules with '-' in the name failed. this fix allows those modules to be loaded when requested. ping d-i-b was pushed ~10 h ago by guillomovitch I just pushed stage2/images/rescue to pick up latest d-i-b. ah, i hadn't seen it... thanks!
Re: [Mageia-dev] no signature errors on latest updates
On Thu 14 Mar 2013 14:00:19 GMT, Johnny A. Solbu wrote: On Thursday 14. March 2013 14.46, isadora wrote: See: https://bugs.mageia.org/show_bug.cgi?id=9385 In my opinion, this should qualify as a release blocker. There is no need to call everything release blocker as soon as a bug is annoying. Here, it's just something annoying that needs to be fixed by the sysadmin team. It happens periodically. Cheers, like... every year around the middle of March :-)
Re: [Mageia-dev] [soft-commits] [7542] - fix loading modules with - in their names (mga#9242)
Op donderdag 14 maart 2013 19:47:36 schreef Thierry Vignaud: On 13 March 2013 20:52, r...@mageia.org wrote: Revision 7542 Author alien Date 2013-03-13 20:52:07 +0100 (Wed, 13 Mar 2013) Log Message - fix loading modules with - in their names (mga#9242) - add an easy buildtarget for testing A couple remarks: - next time do a commit a time (first your change, then bumping version) ah, ok, is there a reason for this (to have separate a change and then a version bump)? now that you mention this, i think i've seen you say this to thomas before... it would've been nice to have had some documentation regarding these things... - please revert your dist-svn-test; when one wants to test, either he commits in git-svn or he locally runs make well, it would've been nicer if you have said so before (or documented it someplace), i spent more than 4 hours figuring out why my changes had no effect... but sure, i'll revert it. I hope you tested several modules with both case? yes, i tried with several. and since the xen-netfront modules aren't autodetected for some reason (i'm trying to look into it), i had the opportunity to test alot with various modules. (also, i note that virtmanager telling to use e1000 or other model, it still uses the netfront one instead..) Modified Paths drakx/trunk/mdk-stage1/Makefile drakx/trunk/mdk-stage1/NEWS drakx/trunk/mdk-stage1/modules.c Modified: drakx/trunk/mdk-stage1/Makefile === --- drakx/trunk/mdk-stage1/Makefile 2013-03-12 19:12:12 UTC (rev 7541) +++ drakx/trunk/mdk-stage1/Makefile 2013-03-13 19:52:07 UTC (rev 7542) @@ -15,7 +15,7 @@ # along with this program; if not, write to the Free Software # Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA. -VERSION=1.74.1 +VERSION=1.75 PRODUCT=drakx-installer-binaries # @@ -217,6 +217,14 @@ fi; $(info $(PRODUCT)-$(VERSION).tar.xz is ready) +dist-svn-test: + mkdir -p $(PRODUCT)-$(VERSION) + svn export -q . $(PRODUCT)-$(VERSION)/mdk-stage1 + svn export -q ../kernel $(PRODUCT)-$(VERSION)/kernel + cp ../Makefile.config $(PRODUCT)-$(VERSION)/ + tar cfa $(PRODUCT)-$(VERSION).tar.xz $(PRODUCT)-$(VERSION) + rm -rf $(PRODUCT)-$(VERSION) + dist-svn: mkdir -p $(PRODUCT)-$(VERSION) svn export -q -rBASE . $(PRODUCT)-$(VERSION)/mdk-stage1
Re: [Mageia-dev] urpmi always use rsync
Op woensdag 13 maart 2013 16:12:11 schreef Guillaume Rousse: Le 13/03/2013 15:01, David Walser a écrit : zezinho lists.jjorge@... writes: in my two cauldron systems, urpmi is now always using rsync, even if another downloader is setup in urpmi.cfg or asked in CLI. I am using default mirrorlist created by edit-urpm-sources.pl. Indeed it does, and even worse, if your network requires a proxy, this totally does not work. Even if you have a proxy configured through drakconf, it still won't use it for rsync. This technically is correct, as that proxy setting is supposed to be just for http/https/ftp, and globally setting the RSYNC_PROXY variable along with those may be undesirable and cause problems with using rsync across your local network. Still, it'd be nice if this could be handled better somehow. I'm just not sure what the right solution is. Quick solution: stop using useless complexity layers without added value, and declare explicitely with mirror url you want to use. You'll also have sane source identifiers, instead of the crappy defaut ones unusable in command line. it annoys me that the spaces seem to break the bash-completion for the media names...
Re: [Mageia-dev] RFC: Patch e2fsprogs to not print the clean message on fsck.
same thing with brtfsck
Op woensdag 13 maart 2013 14:03:02 schreef Colin Guthrie:
'Twas brillig, and Colin Guthrie at 13/03/13 12:35 did gyre and gimble:
Hi,
I would like to propose that we push a patch to e2fsprogs to make it not
print out the clean message when it checks the filesystem.
In my current boot (which is an experiment without initrds), it prints
this message over the top of plymouth and stays during the nice fade
transition to gdm and generally makes the boot ugly.
I believe only the e2fsprogs print this message and the others do not
e.g. see this comparison with XFS:
[root@jimmy ~]# dd if=/dev/zero of=xfs.img bs=1M count=100 /dev/null
21; mkfs.xfs xfs.img /dev/null 21; xfs_check xfs.img
[root@jimmy ~]# dd if=/dev/zero of=ext4.img bs=1M count=100 /dev/null
21; mkfs.ext4 -F ext4.img /dev/null 21; fsck.ext4 -a ext4.img
ext4.img: clean, 11/25688 files, 8896/102400 blocks
My patch would propose to not print the clean message when the -a
option was passed. This is similar logic which prevents showing the
version when -a is passed.
I've not tested this but I will before committing if no-one disapproves
of this approach.
--- e2fsprogs-1.42.7/e2fsck/unix.c.orig 2013-03-13 10:57:22.349126868
+
+++ e2fsprogs-1.42.7/e2fsck/unix.c 2013-03-13 12:33:08.340522834 +
@@ -421,13 +421,14 @@
}
/* Print the summary message when we're skipping a full check */
- log_out(ctx, _(%s: clean, %u/%u files, %llu/%llu blocks),
- ctx-device_name,
- fs-super-s_inodes_count - fs-super-s_free_inodes_count,
- fs-super-s_inodes_count,
- ext2fs_blocks_count(fs-super) -
- ext2fs_free_blocks_count(fs-super),
- ext2fs_blocks_count(fs-super));
+ if (!(ctx-options E2F_OPT_PREEN))
+ log_out(ctx, _(%s: clean, %u/%u files, %llu/%llu blocks),
+ ctx-device_name,
+ fs-super-s_inodes_count -
fs-super-s_free_inodes_count,
+ fs-super-s_inodes_count,
+ ext2fs_blocks_count(fs-super) -
+ ext2fs_free_blocks_count(fs-super),
+ ext2fs_blocks_count(fs-super));
next_check = 10;
if (fs-super-s_max_mnt_count 0) {
next_check = fs-super-s_max_mnt_count - fs-super-
s_mnt_count;
FWIW, this patch is a bit wrong (as it still prints out a newline and
some other fluff about when the next check is etc.) and it causes a test
to fail.
But an updated and tested patch fixes it up. If there are no complaints,
I'll push it.
Cheers
Col
[Mageia-dev] freeze push: drakx-installer-binaries
Please push: drakx-installer-binaries: - fix loading modules with - in their names (mga#9242) in the stage1 window to load extra modules (eg: xen-netfront), all modules with '-' in the name failed. this fix allows those modules to be loaded when requested.
Re: [Mageia-dev] Team elections
Le 05/03/2013 14:06, Anne Nicolas a écrit : [...] People should apply if they want to spend some time on these tasks. This does not mean it's a full time job hopefully but it needs to spend some time on it. Cheers Nobody there? I will not go alone on that. Does that mean there is no more packagers team ? I feel kind of guilty reading this... i don't want Mageia to die out, so if there's no-one else, i can be a helper if you want me...
Re: [Mageia-dev] [changelog] [RPM] cauldron core/release xen-4.2.1-6.mga3
Op zondag 3 maart 2013 11:46:06 schreef Thierry Vignaud: On 3 March 2013 11:27, AL13N al...@rmail.be wrote: alien alien 4.2.1-6.mga3: + Revision: 401170 - Fix creation of log directory now if someone would fix libvirt/virt-manager with xen... working on it, but it looks like i would need native qemu to get the best results. that would mean trowing all around. i am in contact with native to have better build procedure and build against qemu natively, so that qemu itself can build the xen and we have proper support, but it's not ready yet. atm, i'm planning on holding off with that and doing this for mga4. also a problem is that the qdisk driver (which is really needed if you have a file image with libvirt, instead of having LVM partitions) seems to have some kind of bug, in that the remote and local state don't match. How far did you get? i was looking for your email, (i know you sent one), but was unable to find it as told a couple weeks ago, xl/xm top works but libvirt can't connect to xen: Mar 03 10:21:19 localhost libvirtd[833]: erreur interne impossible de se connecter à Xen Mar 03 10:21:19 localhost libvirtd[833]: unable to connect to 'localhost:8000': Connexion refusée Mar 03 10:21:19 localhost libvirtd[833]: this function is not supported by the connection driver: virConnectNumOfInterfaces Mar 03 10:21:20 localhost libvirtd[833]: this function is not supported by the connection driver: virConnectNumOfInterfaces Mar 03 10:21:21 localhost libvirtd[833]: this function is not supported by the connection driver: virConnectNumOfInterfaces Mar 03 10:21:49 localhost libvirtd[833]: No response from client 0x14423a0 after 5 keepalive messages in 30 seconds see https://wiki.mageia.org/en/XEN atm, i'm almost successfull, but it seems you need to have a kernel in the image for paravirtualisation, due to libvirtd using pygrub. which i'm normally not using... (i also found a libvirt connection bug)
Re: [Mageia-dev] [changelog] [RPM] cauldron core/release xen-4.2.1-6.mga3
Op zondag 3 maart 2013 11:46:06 schreef Thierry Vignaud: On 3 March 2013 11:27, AL13N al...@rmail.be wrote: alien alien 4.2.1-6.mga3: + Revision: 401170 - Fix creation of log directory now if someone would fix libvirt/virt-manager with xen... working on it, but it looks like i would need native qemu to get the best results. that would mean trowing all around. i am in contact with native to have better build procedure and build against qemu natively, so that qemu itself can build the xen and we have proper support, but it's not ready yet. atm, i'm planning on holding off with that and doing this for mga4. also a problem is that the qdisk driver (which is really needed if you have a file image with libvirt, instead of having LVM partitions) seems to have some kind of bug, in that the remote and local state don't match. How far did you get? i was looking for your email, (i know you sent one), but was unable to find it as told a couple weeks ago, xl/xm top works but libvirt can't connect to xen: Mar 03 10:21:19 localhost libvirtd[833]: erreur interne impossible de se connecter à Xen Mar 03 10:21:19 localhost libvirtd[833]: unable to connect to 'localhost:8000': Connexion refusée Mar 03 10:21:19 localhost libvirtd[833]: this function is not supported by the connection driver: virConnectNumOfInterfaces Mar 03 10:21:20 localhost libvirtd[833]: this function is not supported by the connection driver: virConnectNumOfInterfaces Mar 03 10:21:21 localhost libvirtd[833]: this function is not supported by the connection driver: virConnectNumOfInterfaces Mar 03 10:21:49 localhost libvirtd[833]: No response from client 0x14423a0 after 5 keepalive messages in 30 seconds my tests were successfull in both HVM and PV now.
[Mageia-dev] XEN (known issues)
i've finally been able to make XEN work... (with libvirtd and virt-manager) albeit with some issues... see https://wiki.mageia.org/en/XEN for anyone wishing to try it. is this something that should be added to errata for mga3? it seems most of the problems are libvirtd related issues with their xen module. WDYT?
Re: [Mageia-dev] [Bug 5199] Several error with ocaml bytecode compilation in ocaml-xen module
Op zondag 10 maart 2013 17:33:28 schreef Florent Monnier: ocaml-xen should be split in ocaml-xen and ocaml-xen-devel, (2013-03-04) [...] what kind of filenames should be in -devel and which in regular package? main package: - .cma .cmi .cmo .cmxs .so META .so.owner (and README, LICENSE, etc...) devel package: - .a .cmxa .cmx .o .mli .ml (and documentation) For more details, read here: https://wiki.mageia.org/en/OCaml_policy should some files be deleted? ie: the .a files? If you don't know just don't delete anything, just provide what the install script did installed. Anyway if there is something installed (by error) it won't have bad effects on the real parts of the lib. in any case, i'm asking because we do have a policy of remove all static libs (.a) and .la files. i just wasn't sure the .a files were static libs in this case, or just something completely unrelated. but since the others have .so, i think they are static libs. also, usually there are versioned .so files and the .so files themselves need to be in -devel; i guess it's not so for ocaml packages... For any question, don't hesitate to ask to the current ocaml packagers, they are listed at the beginning of this page: https://wiki.mageia.org/en/OCaml_Packaging Also for any issue, or TODO things you can also use the ocaml wiki pages. did i accidentally reply to a br mail? i thought i put this in the bugreport, but i guess i'm not sure?
Re: [Mageia-dev] [Bug 5199] Several error with ocaml bytecode compilation in ocaml-xen module
Op zondag 10 maart 2013 17:33:28 schreef Florent Monnier: ocaml-xen should be split in ocaml-xen and ocaml-xen-devel, (2013-03-04) [...] what kind of filenames should be in -devel and which in regular package? main package: - .cma .cmi .cmo .cmxs .so META .so.owner (and README, LICENSE, etc...) devel package: - .a .cmxa .cmx .o .mli .ml (and documentation) For more details, read here: https://wiki.mageia.org/en/OCaml_policy should some files be deleted? ie: the .a files? If you don't know just don't delete anything, just provide what the install script did installed. Anyway if there is something installed (by error) it won't have bad effects on the real parts of the lib. in any case, i'm asking because we do have a policy of remove all static libs (.a) and .la files. i just wasn't sure the .a files were static libs in this case, or just something completely unrelated. but since the others have .so, i think they are static libs. also, usually there are versioned .so files and the .so files themselves need to be in -devel; i guess it's not so for ocaml packages... For any question, don't hesitate to ask to the current ocaml packagers, they are listed at the beginning of this page: https://wiki.mageia.org/en/OCaml_Packaging Also for any issue, or TODO things you can also use the ocaml wiki pages. did i accidentally reply to a br mail? i thought i put this in the bugreport, but i guess i'm not sure?
Re: [Mageia-dev] [changelog] [RPM] cauldron core/release xen-4.2.1-7.mga3
On 3 March 2013 15:35, alien buildsystem-dae...@mageia.org wrote: Name: xen Relocations: (not relocatable) Version : 4.2.1 Vendor: Mageia.Org Release : 7.mga3Build Date: Sun Mar 3 15:28:13 2013 Install Date: (not installed) Build Host: jonund.mageia.org Group : System/Kernel and hardwareSource RPM: (none) Size: 39692824 License: GPL Signature : (none) Packager: alien alien URL : http://xen.org/ Summary : The basic tools for managing XEN virtual machines Description : The basic tools for managing XEN virtual machines. alien alien 4.2.1-7.mga3: + Revision: 401283 - typo in filename - helperscripts are only moved if different arch - Move helper scripts to location they are looked after by various scripts and hardcoded binaries See https://bugs.mageia.org/show_bug.cgi?id=9294 xencommons service fails to start on legacy hw (w/o hw support for virt) systemctl status xencommons.service xencommons.service - LSB: Start/stop xenstored and xenconsoled Loaded: loaded (/etc/rc.d/init.d/xencommons) Active: failed (Result: exit-code) since Fri, 2013-03-08 06:56:33 CET; 1min 59s ago Process: 685 ExecStart=/etc/rc.d/init.d/xencommons start (code=exited, status=127) CGroup: name=systemd:/system/xencommons.service ├ 825 /usr/sbin/oxenstored --pid-file /var/run/xenstored.pid └ 838 xenconsoled --pid-file=/var/run/xenconsoled.pid Mar 08 06:56:32 localhost xencommons[685]: Starting oxenstored... Mar 08 06:56:32 localhost xencommons[685]: Setting domain 0 name... Mar 08 06:56:32 localhost xencommons[685]: Starting xenconsoled... Mar 08 06:56:32 localhost xencommons[685]: Starting QEMU as disk backend for dom0 Mar 08 06:56:32 localhost xencommons[685]: /etc/rc.d/init.d/xencommons: ligne119: /usr/lib/xen/bin/qemu-system-i386: No such file or directory Mar 08 06:56:33 localhost systemd[1]: Failed to start LSB: Start/stop xenstored and xenconsoled. Mar 08 06:56:33 localhost systemd[1]: Unit xencommons.service entered failed state It's in /usr/bin, not in /usr/lib/xen/bin... (/etc/sysconfig/xencommons needs fixing) And it lacks a require on qemu 1. /usr/lib/xen/bin/qemu-system-i386 is where the qemu-upstream version is (which we don't ship), we should switch this to traditional: /usr/lib/xen/bin/qemu-dm but... xencommons isn't supposed to be run anymore (unless you're using xend). normally, we only need 'xenconsoled' and 'xenstored' for the xl service. 2. if you don't have hardware virt support, i would think it's normal that it fails to start? 3. you don't need qemu to run xen, if you run paravirtualisation only, there is no need for qemu. so definately not a requirement.
Re: [Mageia-dev] A question about BuildRequires and other RPM questions.
On 08/03/13 11:18, Robert Wood wrote: [...] I still don't get this whole trial and error thing. It seems that you might submit something to the repositories that someone finds doesn't install because of a missing dependency and you redo it. Then you can retry that for up to five goes before it finally works? That seems crazy. I must have misunderstood. well, if we submit packages, the buildsystem uses the buildrequires and such to build the packages. if the package fails to build (due to missing buildrequire) the package is never submitted and we get an email back to us or we can follow the built packages on the buildsystem: see http://pkgsubmit.mageia.org/ for examples. also, buildrequires have nothing to do with regular requires or what normal users come into contact with. thus finding buildrequires is trial and error for the packager if he's making a new package, but only the first time and even then, after you acquire the skillset, this only takes maximum a few hours (unless it's java :-) ). but the best way to understand is to just try it. the simplest way to start making a package is to first make a src.rpm out of a tarball (with a spec in it) and then rebuild it. 1. find a tarball which includes a spec file. (or put one in it) 2. rpmbuild -ts file.tar.gz 3. rpmbuild --rebuild file.src.rpm starting small is the way to get there. I have no problem learning stuff, I do it every single day in my work and it's what makes it so enjoyable, but maybe I need to take smaller steps first? No idea where to start or how to go about doing that though. As I might not have any work in a week's time it would potentially be an ideal time to learn, but maybe I'm just not the right person to do this? a mentor would definately help, i assume noone has stepped forward for you yet?
Re: [Mageia-dev] Why is AHCI statically compiled into kernel?
Op donderdag 7 maart 2013 12:18:09 schreef Anne Wilson: On 07/03/13 12:03, AL13N wrote: On 07/03/13 04:38, R James wrote: [...] So the 'nickname' feature you request is available with a little pre-install preparation and post-install config file editing. Hope this helps -- RJ Thanks. It will help a lot for my own use. However, that really needs to be included in the gui disk partitioning, so that people can find and use it. I'm fairly sure there is no way to do that at present. imho: dolphin already shows the filesystem label; but, imho, there is no need to use label instead of uuid on the inside... it's not like most people actually look into fstab... i'm not sure, but i thought the expert had a way to change label in filesystems in the partitioner. label isn't used in fstab, but i don't think it should. OK - when I partition, I do add an identifier, which may be what jpbfree referred to, but what I see in Dolphin is not, IMO, very helpful. The shortcut added to Places shows the long number, not Win_C or anything like that. Maybe this is a Dolphin fault - I don't know. Anne i've always seen the labels of the USB-sticks and such, and they are also just filesystem labels. also i've seen at least in the past also the labels of other filesystems that i didn't mount
Re: [Mageia-dev] [changelog] [RPM] cauldron core/release libvirt-1.0.2-4.mga3
Op vrijdag 8 maart 2013 07:15:48 schreef Thierry Vignaud: On 8 March 2013 01:50, alien buildsystem-dae...@mageia.org wrote: alien alien 1.0.2-4.mga3: + Revision: 401739 - XEN: do not force blktap as disk backend Still: # service libvirtd status Redirecting to /bin/systemctl status libvirtd.service libvirtd.service - Virtualization daemon Loaded: loaded (/usr/lib/systemd/system/libvirtd.service; enabled) Active: active (running) since Fri, 2013-03-08 07:12:14 CET; 2min 48s ago Main PID: 860 (libvirtd) CGroup: name=systemd:/system/libvirtd.service ├ 860 /usr/sbin/libvirtd └ 1280 dnsmasq --conf-file=/var/lib/libvirt/dnsmasq/default.conf Mar 08 07:12:59 localhost libvirtd[860]: Unable to issue hypervisor ioctl 3166208: Permission non accordée Mar 08 07:12:59 localhost libvirtd[860]: Unable to issue hypervisor ioctl 3166208: Permission non accordée Mar 08 07:12:59 localhost libvirtd[860]: Unable to issue hypervisor ioctl 3166208: Permission non accordée Mar 08 07:12:59 localhost libvirtd[860]: erreur interne impossible de se connecter à Xen Mar 08 07:12:59 localhost libvirtd[860]: unable to connect to 'localhost:8000': Connexion refusée Mar 08 07:12:59 localhost libvirtd[860]: this function is not supported by the connection driver: virConnectNumOfInterfaces Mar 08 07:13:00 localhost libvirtd[860]: this function is not supported by the connection driver: virConnectNumOfInterfaces Mar 08 07:13:01 localhost libvirtd[860]: this function is not supported by the connection driver: virConnectNumOfInterfaces Mar 08 07:13:02 localhost libvirtd[860]: this function is not supported by the connection driver: virConnectNumOfInterfaces Mar 08 07:13:28 localhost libvirtd[860]: No response from client 0x21d39b0 after 5 keepalive messages in 30 seconds either try to connect to xen://127.0.0.1/ or ssh+xen://127.0.0.1/ . (as a remote machine) that, or use xend and xm commands (supposedly xend works better with libvirt rather than xenlight) i see connection refused, so, is port 8000 actually running? and/or firewalled? check with netstat -lntop if 8000 is in use by xend. it seems to fall back to libxl... maybe if you change default.xml file to have bridge name=br0 / forward mode=bridge / (this is if you have an existing bridge) this is because libxl doesn't manage a bridge and/or networking. libxl mentions that the user should set up a bridge on your system with network scripts. so in short, there's 2 ways to do xen (+libvirt) and you're somewhere in between atm...
Re: [Mageia-dev] Why is AHCI statically compiled into kernel?
Op woensdag 6 maart 2013 13:46:06 schreef Anne Wilson: On 05/03/13 17:11, Colin Guthrie wrote: Anything that relies on ordering is just broken by design. We need to handle things gracefully regardless of the order they are detected. This is why UUIDs are the defacto method for filesystem identification these days and why in mga4 we'll likely switch to a consistent naming scheme for networking devices too. While I appreciate the intention, from a user PoV, those UUIDs mean b* all. It would be really nice if, when they are first named, it was possible to allocate a nickname for want of a better term. if you use it, filesystems also have label functionalities, which iinm are shown in dolphin.
Re: [Mageia-dev] Why is AHCI statically compiled into kernel?
Op dinsdag 5 maart 2013 20:10:20 schreef Thomas Backlund: [...] For servers ( bigger workstations) where you rely on SCSI / SAS / FC / you still need initrds, and usually you dont really care if a boot take a little longer. does this mean that AHCI is enabled only for desktop kernels?
Re: [Mageia-dev] [changelog] [RPM] cauldron core/release xen-4.2.1-6.mga3
Op zondag 3 maart 2013 10:40:33 schreef Thierry Vignaud: On 2 March 2013 23:30, alien buildsystem-dae...@mageia.org wrote: alien alien 4.2.1-6.mga3: + Revision: 401170 - Fix creation of log directory now if someone would fix libvirt/virt-manager with xen... working on it, but it looks like i would need native qemu to get the best results. that would mean trowing all around. i am in contact with native to have better build procedure and build against qemu natively, so that qemu itself can build the xen and we have proper support, but it's not ready yet. atm, i'm planning on holding off with that and doing this for mga4. also a problem is that the qdisk driver (which is really needed if you have a file image with libvirt, instead of having LVM partitions) seems to have some kind of bug, in that the remote and local state don't match. How far did you get? i was looking for your email, (i know you sent one), but was unable to find it
Re: [Mageia-dev] [changelog] [RPM] cauldron core/release xen-4.2.1-6.mga3
Op zondag 3 maart 2013 11:46:06 schreef Thierry Vignaud: On 3 March 2013 11:27, AL13N al...@rmail.be wrote: alien alien 4.2.1-6.mga3: + Revision: 401170 - Fix creation of log directory now if someone would fix libvirt/virt-manager with xen... working on it, but it looks like i would need native qemu to get the best results. that would mean trowing all around. i am in contact with native to have better build procedure and build against qemu natively, so that qemu itself can build the xen and we have proper support, but it's not ready yet. atm, i'm planning on holding off with that and doing this for mga4. also a problem is that the qdisk driver (which is really needed if you have a file image with libvirt, instead of having LVM partitions) seems to have some kind of bug, in that the remote and local state don't match. How far did you get? i was looking for your email, (i know you sent one), but was unable to find it as told a couple weeks ago, xl/xm top works but libvirt can't connect to xen: Mar 03 10:21:19 localhost libvirtd[833]: erreur interne impossible de se connecter à Xen Mar 03 10:21:19 localhost libvirtd[833]: unable to connect to 'localhost:8000': Connexion refusée Mar 03 10:21:19 localhost libvirtd[833]: this function is not supported by the connection driver: virConnectNumOfInterfaces Mar 03 10:21:20 localhost libvirtd[833]: this function is not supported by the connection driver: virConnectNumOfInterfaces Mar 03 10:21:21 localhost libvirtd[833]: this function is not supported by the connection driver: virConnectNumOfInterfaces Mar 03 10:21:49 localhost libvirtd[833]: No response from client 0x14423a0 after 5 keepalive messages in 30 seconds how do you connect? on both mga2 and cauldron i was able to connect. i use xen+ssh://root@10.238.9.54/ . it seems you're connecting to the http interface? is the http interface running? that only works with xm / xend. i didn't use the xend/xm setup. i started only xenstored and xenconsoled, enough to use the xl tools. i noticed that the way i connect libvirt actually uses the xl tools, so that went ok. i do had some trouble, like the log directory didn't exist, so libvirt failed to create a machine. and now i have some issue with xen-blkfront and xen-netfront to get a machine installed... (i have a pxe installer system)
[Mageia-dev] libvirt-utils requires policykit?
and gamin, making it pull in oxygen etc... libvirt-utils is meant for dedicated servers too... is this really required?
Re: [Mageia-dev] Bug #7633
Op donderdag 28 februari 2013 11:27:14 schreef Sander Lepik: https://bugs.mageia.org/show_bug.cgi?id=7633 Can we do something about this bug? 80+ people in CC getting spammed every second day. If we can't fix it then let's drop it. i agree
Re: [Mageia-dev] A question about BuildRequires and other RPM questions.
Op donderdag 28 februari 2013 15:43:22 schreef Robert Wood: On 28/02/13 14:25, Guillaume Rousse wrote: There is not much choice, beside building from a specified build environment, which is usually the minimal installation for your target distribution + rpmbuild. Most distributions use dedicated systems to automatically deploy such clean environment before eac package build attempt (iurt, mock, etc...). So, I should maybe install a minimal install on a virtual machine? Then when it needs packages I can add those to the dependencies list? It strikes me the problem with that would be that once you've added a load of packages for one RPM, then started on another, you'd be back to the same problem as before and need to keep reinstalling Mageia for each RPM you do. There must be a better way than that. i myself have made a script that uses a minimal install btrfs subvolume, makes a snapshots for this package, then builds the rpm in a screen session, then removes the snapshot again. i use this script mostly for testbuilding on my local machine. in the past i just submitted it to the buildsystem (to updates_testing) when i was done working on it, and if it failed, i added some extra buildrequires, until it built, after that i did a final test Build dependencies are usually specified in installation instructions. For humans, of course. You may also try to parse the outpout of ./configure (or equivalent) script. In both case, there is not garanty then every build dependency will get specified. It sounds like there is a load of trial and error then? I am sure I must misunderstand, building reliable RPMs must be a relatively straightforward thing once you're up and running surely? trial and error for buildrequires yes, mostly for new packages, if you're updateing packages, you sort of know more about the package and if it has extra builddependencies, the BS will tell you this. so, in short for new packages you can have some trial and error (usually no more than 5 or 6 tries, wrt buildrequires). it's not such a big deal...
Re: [Mageia-dev] About bug 6676
Op donderdag 21 februari 2013 14:04:31 schreef Pierre-Malo Deniélou: On 21/02/13 12:12, Dan Fandrich wrote: On Thu, Feb 21, 2013 at 12:02:13PM +, Pierre-Malo Deniélou wrote: I would say that packages which autodownload non-free material should be in nonfree (like get-skype). For the same reason that free packages which Require a package in nonfree should be in nonfree. But what happens when free content becomes available so that the non-free download is no longer required? This is unlikely in the case of Skype, but has happened with other games engines in the past. If it becomes free, we push the newer version to the free repository. Fairly simple :-). Cheers, except that if this package is free and dependant on nonfree other package or content. the moment this changes, it means that the old package becomes completely free without having any changes. with games this is a possibility. with respect to this, i would prefer it to be possible to have a gaming engine in free if it's free, even if there's content that is nonfree...; especially if it's theorethically possible for free content to be added. it would mean that people developing free content for such a game (or starting such development) would not need to enable nonfree...
Re: [Mageia-dev] Package request with src.rpms
Op dinsdag 19 februari 2013 15:52:08 schreef atilla ontas: Hi there. I merely working on zemberek and its dependencies for Mageia Cauldron. As a Turkish sporen guy; i'd like to see zemberek in repositories. Zemberek is a natural language processing library for Turkic languages (Turkish, Azerbaijanin, Turkmen etc.), It is written in java. Altough its development stalled since 2010; it is still working on Magea, Also zemberek is the only true Turkish spell checking app. Aspell-tr won't do right corrections. Zemberek needs apache-mina 1.8, libmatthew-java, slfj4 and dbus-java packages to run. While it won't work apache-mina package in official repositores; i decided to apache-mina-1.1.7 in zemberek-server package; also i patched libmatthew-java due to bug#9002https://bugs.mageia.org/show_bug.cgi?id=9002. Also i hava made package for Al-Anvar, a Holy Qur'an study tool. So, if you mind to inspect, review and add to repositories those apps it will be awesome. I'm willing to be a packager but have little time to work on packages due to my job and familiy, AItough i can not attend weekly meetings most of time, still is it possible? May i find a mentor? alot of us have jobs and family and little time, even if you only maintain your packages, that is fine. you can contribute and find a mentor no problem. on the mageia wiki page, there's some information on packaging and our policies, and there's also a page for you to put your name to find a mentor. but, nothing stops you from already contributing if you don't have a mentor, you can already file bug reports for new packages, and attach your spec files for review. also, on #mageia-mentoring, you can always ask for questions on policies or packaging, even if you don't have a mentor yet. also the meetings are public on IRC, and we have meeting logs, so if you want to be up2date regarding the meetings, you can read the logs. i also advise you to subscribe to the mageia-dev mailing list, since that one has sometimes crucial info on packaging. good luck
Re: [Mageia-dev] System doen't boot with LVM
I rebooted my laptop this morning and it failed to boot: unable to find my / under lvm. I did try to do a fresh cauldron result but got same result. Dracut gi a shell, It seems 'lvm vgmknodes' has no effect (the swap lv did existed already). BTW: lvm command seems to be missing in rescue mode. It is impossible to use an already existing encrypted partition: it said 'cryptsetup failed' and nothing more. i think rescue mode has lvm2 command
Re: [Mageia-dev] freeze push: perl-URPM-4.26 urpmi-7.19
Op zaterdag 9 februari 2013 22:35:47 schreef Thierry Vignaud: Hi Please let in perl-URPM-4.26 urpmi-7.19 I got rid of playing with rpm -Uvh --oldpackage foobar*rpm libfoobarX*rpm, so I added basic support for --downgrade (mga#6655). [...] ooh, this is nice!
Re: [Mageia-dev] [RFC] rsyslog vs journalctl
'Twas brillig, and David Walser at 06/02/13 18:28 did gyre and gimble: [...] What I guess we could to to avoid putting rsyslog on the physical media would be to put a versioned conflicts in the main systemd package with rsyslog and syslog-ng. Thus the old packages should be removed when upgrading (AIUI). not a really good idea imho, i have a server which uses rsyslog for network remote syslogging... so upgrading that would break this. what about the tty12 bug? can this be fixed with journald? it seems to be a feature that people don't want to lose?
Re: [Mageia-dev] [RFC] rsyslog vs journalctl
'Twas brillig, and Anne Nicolas at 06/02/13 08:43 did gyre and gimble: There was a discussion yesterday evening in packager meeting about what we should do with rsyslog. It's needed for upgrade from Mageia 2. But journalctl is now installed by default. Is there some requirement for systemd ? Shall we have both installed? We need an answer to deal with upgrade and isos [...] I'm afraid it might not be as easy as anyone would think: 1. journald does not do UDP remote syslogging, according to lennart at his talk at FOSDEM? == this means old syslog shouldn't be obsoleted 2. it appears it also doesn't fill tty12 with info as rsyslog does == if true, and not fixable, then i would still suggest to have both.
Re: [Mageia-dev] freeze push: munin
Please push munin 2.0.11, it's a bugfix release. Wow, it's already done, wonderful ! :)
Re: [Mageia-dev] [Mageia-sysadm] Please remove qemu, and qemu-img from Mageia 3.
Op zondag 3 februari 2013 03:45:59 schreef David W. Hodgins: During testing of updates to qemu, and x11-driver-video-qxl, it has become very clear that no-one could possibly be using these packages, as they are so slow, as to be useless. Over 6 hours to do a net install of a kde x86-64 system, on hardware where that would normally be under 20 minutes. There are many problems with xorg crashing, mouse pointer not being where the pointer is shown, etc. These bugs are described in https://bugs.mageia.org/show_bug.cgi?id=8938 Please drop these useless packages, so we don't have to test or install security updates for them. Thanks, Dave Hodgins i use qemu-img to convert kvm images to vmdk
Re: [Mageia-dev] x11-driver-video-qxl/qemu/libvirt (was Re: Please remove qemu, and qemu-img from Mageia 3.)
Op dinsdag 5 februari 2013 00:09:52 schreef Christiaan Welvaart: On Sun, 3 Feb 2013, David W. Hodgins wrote: During testing of updates to qemu, and x11-driver-video-qxl, it has become very clear that no-one could possibly be using these packages, as they are so slow, as to be useless. Qemu (or rather each qemu-system-*) is an emulator at its core, so slowness is not a huge surprise. You probably wanted to run it in (fast) virtualization mode - use qemu-kvm for that (and the kvm module for your cpu must be loaded to get virtualization working). But running qemu directly is tiresome, try virt-manager - it works about as well as virtualbox even if I need to run it as root. I use virt-manager/qemu-kvm to build+test mga2 updates for iceape, only graphics (spice+vmvga) is slow (but better than vnc+cirrus). Unfortunately people keep updating libvirt, apparently without testing it - now it is broken again in cauldron. I need to kill all the qemu-system-* and qemu-kvm that libvirtd starts one by one before virt-manager can connect. There are many problems with xorg crashing, mouse pointer not being where the pointer is shown, etc. These bugs are described in https://bugs.mageia.org/show_bug.cgi?id=8938 A month ago I updated the spice packages; I also tried to update x11-driver-video-qxl (which is part of spice AFAIK) but it did not work at all. So if you ask for *that* package to be removed, fine with me. Christiaan no, please,... get it working instead :-)
Re: [Mageia-dev] Mariadb 5.5.29?
Op donderdag 31 januari 2013 19:47:59 schreef David Walser: FundaWang fundawang@... writes: Hello, Would pushing mariadb 5.5.29 be a good choice? It seems that there are two many security fixes in this release[1]. [1]: https://kb.askmonty.org/en/mariadb-5529-release-notes/ Thanks for bringing this up. Looks like it would be good to have for Mageia 2 and Cauldron. please don't i'm working on things... i will stop at 5.5.28 for cauldron (and security patch it upwards) just like i done with 5.5.25 for mga1. perhaps in the near future we might go higher, but definately not now. there are changes in the versioning builds, which makes our versioning hacks fail... this needs to be tested better; and since we're this far, i'm not planning to update it. (for now).
Re: [Mageia-dev] Packagers meeting
Hi there We will have our weekly meeting tomorrow, 20h UTC: - quick beta 2 review - release critical bugs review (this one should take most of our time) As usual feel free to propose a topic. QA and bug triage team, could you please be around? if possible, i would like to have some kind of status (planning) of bug 2317: - iinm it was decided to fix (was there a timeframe set?) - is there something anyone can help with, do we commit some patches? - or is it now only on tv to actually have the time to do the work? (preferably in the beginning of the meeting)
Re: [Mageia-dev] [council] *ping* Media query: secure boot support
On Tue, Jan 29, 2013 at 10:02 AM, Guillaume Rousse guillomovi...@gmail.com wrote: Le 29/01/2013 10:37, Wolfgang Bornath a écrit : As for now Microsoft requires all W8 certified systems with secure boot to allow secure boot to be switched off by user/sysadmin. One reason why I do not understand the reason why all these people (Garret et all) are stumbling all over themselves to solve a problem which is not even sure to ever come by. I guess that's because secure boot may be considered useful, if you're in control of it, of course. And because something working out of the box is probably better when targetting non-experts. Yes I think the main problem is that for probably 10 years it had became easy for someone non technical to test/install linux, now they would need to change setup in the bios and would probably give up (or be scared). no 100% sure, but some time ago, i remember someone looking into this with motherboard/PC manufacturers and it seemed like most manufacturers weren't even planning on having secure boot / let alone enable it by default. I suspect that most PC manufacturers are putting the win8 sticker on it regardless of it using secure boot. and i think that most win8 preinstalled PCs won't even be able to use secure boot. in other words... is this REALLY gonna be an issue? (except for ARM platforms)? i'm not 100% sure on this, but i'm not really that worried atm...
Re: [Mageia-dev] FOSDEM - friday evening
Hi there, I will arrive in Buxelles on Friday evening. So anyone of you would like to have some beer and pizza with me, just tell me... Oliver well, i'm picking up sebsebseb and coling at the airport, so i think us three are up for that... :-) at what time are you arriving?
Re: [Mageia-dev] Power consumption disaster with AMD open source drivers
Op woensdag 30 januari 2013 00:57:44 schreef Mustafa Muhammad: Hi, I reported a bug because open source driver for AMD cards reduced my laptops batter life to half: https://bugs.mageia.org/show_bug.cgi?id=8891 Please either implement the solution (shipping two xorg-server packages and choosing from them during install), or extend the life of Mageia 2 to 5 years (or at least 3), nobody can keep using Mageia to kill his battery life. I know I asked about this before but it is critical. Regards I might be mistaken, but i think there is work going on to make this happen... if it does, it'll need some manual intervention though... (but unsure on this), we'll have to see...
Re: [Mageia-dev] Power consumption disaster with AMD open source drivers
Op woensdag 30 januari 2013 06:29:08 schreef Mustafa Muhammad: On 01/30/2013 02:01 AM, AL13N wrote: Op woensdag 30 januari 2013 00:57:44 schreef Mustafa Muhammad: Hi, I reported a bug because open source driver for AMD cards reduced my laptops batter life to half: https://bugs.mageia.org/show_bug.cgi?id=8891 Please either implement the solution (shipping two xorg-server packages and choosing from them during install), or extend the life of Mageia 2 to 5 years (or at least 3), nobody can keep using Mageia to kill his battery life. I know I asked about this before but it is critical. Regards I might be mistaken, but i think there is work going on to make this happen... if it does, it'll need some manual intervention though... (but unsure on this), we'll have to see... Anything is OK, manual intervention or completely manual setup is OK, just don't leave us in the cold by only supporting xorg 1.13 i am not certain, but i believe i have heard this. I too suffer from this problem, even though the real problem is AMD/ATI behaving cruelly and not suppporting their slightly older hardware
Re: [Mageia-dev] [changelog] cauldron core/release task-obsolete-3-56.mga3
Op zondag 27 januari 2013 18:53:10 schreef David Walser: zezinho wrote: Name: task-obsoleteRelocations: (not relocatable) Version : 3 Vendor: Mageia.Org Release : 56.mga3 Build Date: Sun Jan 27 12:28:18 2013 zezinho zezinho 3-56.mga3: + Revision: 392711 - zsnes removed Why!?? I don't want this removed from my system! a reason to why it was removed would've been better
Re: [Mageia-dev] [changelog] [RPM] cauldron core/release lcdproc-0.5.6-6.mga3
Op zondag 27 januari 2013 17:05:20 schreef Thierry Vignaud: On 24 January 2013 00:44, alien buildsystem-dae...@mageia.org wrote: alien alien 0.5.6-6.mga3: + Revision: 391755 + rebuild (emptylog) what for? autobuild failed that release, but for some reason i had to bump release anyway... i donno how to fix this properly. what should i do with revision logs?
Re: [Mageia-dev] [changelog] [RPM] cauldron core/release lcdproc-0.5.6-6.mga3
Op zondag 27 januari 2013 17:43:50 schreef Thierry Vignaud: On 27 January 2013 17:32, AL13N al...@rmail.be wrote: alien alien 0.5.6-6.mga3: + Revision: 391755 + rebuild (emptylog) what for? autobuild failed that release, but for some reason i had to bump release anyway... rebuild did succeeded: * Sat Jan 12 2013 umeabot umeabot 0.5.6-2.mga3 + Revision: 356696 - Mass Rebuild - https://wiki.mageia.org/en/Feature:Mageia3MassRebuild and it was rebuild again later. You should have stopped when seeing you'd to bump release as that mean that previous build was successful.. i donno how to fix this properly. what should i do with revision logs? not the mass rebuild, but on of the autobuilds kept showing lcdproc as failed. i had to rebuild it for it to show up properly. it meant i had a personal entry on check.mageia.org
Re: [Mageia-dev] [changelog] [RPM] cauldron core/release lcdproc-0.5.6-6.mga3
Op zondag 27 januari 2013 17:18:01 schreef Pascal Terjan: On Sun, Jan 27, 2013 at 5:05 PM, Pascal Terjan pter...@gmail.com wrote: On Sun, Jan 27, 2013 at 4:50 PM, AL13N al...@rmail.be wrote: Op zondag 27 januari 2013 17:43:50 schreef Thierry Vignaud: On 27 January 2013 17:32, AL13N al...@rmail.be wrote: alien alien 0.5.6-6.mga3: + Revision: 391755 + rebuild (emptylog) what for? autobuild failed that release, but for some reason i had to bump release anyway... rebuild did succeeded: * Sat Jan 12 2013 umeabot umeabot 0.5.6-2.mga3 + Revision: 356696 - Mass Rebuild - https://wiki.mageia.org/en/Feature:Mageia3MassRebuild and it was rebuild again later. You should have stopped when seeing you'd to bump release as that mean that previous build was successful.. i donno how to fix this properly. what should i do with revision logs? not the mass rebuild, but on of the autobuilds kept showing lcdproc as failed. i had to rebuild it for it to show up properly. it meant i had a personal entry on check.mageia.org If you just rebuild it without fixing anything, it will come back next time... Looking at the failure logs: gcc -fPIC -Wall -O3 -Wno-unused-function -shared -o hd44780.so hd44780-hd44780.o libLCD.a hd44780-hd44780-serial.o hd44780-hd44780-lis2.o hd44780-hd44780-usblcd.o hd44780-hd44780-4bit.o hd44780-hd44780-ext8bit.o hd44780-lcd_sem.o hd44780-hd44780-winamp.o hd44780-hd44780-serialLpt.o hd44780-hd44780-bwct-usb.o hd44780-hd44780-lcd2usb.o hd44780-hd44780-uss720.o hd44780-hd44780-usbtiny.o hd44780-hd44780-usb4all.o hd44780-hd44780-ftdi.o hd44780-hd44780-ethlcd.o hd44780-hd44780-i2c.o -lusb -lftdi -lusb libbignum.a -ldl gcc: error: libbignum.a: No such file or directory make[3]: *** [hd44780.so] Error 1 make[3]: Leaving directory `/home/pterjan/rpmbuild/BUILD/lcdproc-0.5.6/server/drivers' So in the Makefile in server/drivers, hd44780.so needs to depend on libbignum.a hd44780_LDADD = libLCD.a @HD44780_DRIVERS@ @LIBUSB_LIBS@ @LIBFTDI_LIBS@ libbignum.a hd44780_DEPENDENCIES = @HD44780_DRIVERS@ so, i should move it to dependencies instead of ldadd in the Makefile.am and use autoreconf -i instead... but... this isn't the only driver, does this mean i'll have to change dependencies for almost all these drivers? /me sighs
Re: [Mageia-dev] [changelog] [RPM] cauldron core/release lcdproc-0.5.6-6.mga3
Op zondag 27 januari 2013 20:45:20 schreef Pascal Terjan: On Sun, Jan 27, 2013 at 7:14 PM, AL13N al...@rmail.be wrote: Op zondag 27 januari 2013 17:18:01 schreef Pascal Terjan: On Sun, Jan 27, 2013 at 5:05 PM, Pascal Terjan pter...@gmail.com wrote: On Sun, Jan 27, 2013 at 4:50 PM, AL13N al...@rmail.be wrote: Op zondag 27 januari 2013 17:43:50 schreef Thierry Vignaud: On 27 January 2013 17:32, AL13N al...@rmail.be wrote: alien alien 0.5.6-6.mga3: + Revision: 391755 + rebuild (emptylog) what for? autobuild failed that release, but for some reason i had to bump release anyway... rebuild did succeeded: * Sat Jan 12 2013 umeabot umeabot 0.5.6-2.mga3 + Revision: 356696 - Mass Rebuild - https://wiki.mageia.org/en/Feature:Mageia3MassRebuild and it was rebuild again later. You should have stopped when seeing you'd to bump release as that mean that previous build was successful.. i donno how to fix this properly. what should i do with revision logs? not the mass rebuild, but on of the autobuilds kept showing lcdproc as failed. i had to rebuild it for it to show up properly. it meant i had a personal entry on check.mageia.org If you just rebuild it without fixing anything, it will come back next time... Looking at the failure logs: gcc -fPIC -Wall -O3 -Wno-unused-function -shared -o hd44780.so hd44780-hd44780.o libLCD.a hd44780-hd44780-serial.o hd44780-hd44780-lis2.o hd44780-hd44780-usblcd.o hd44780-hd44780-4bit.o hd44780-hd44780-ext8bit.o hd44780-lcd_sem.o hd44780-hd44780-winamp.o hd44780-hd44780-serialLpt.o hd44780-hd44780-bwct-usb.o hd44780-hd44780-lcd2usb.o hd44780-hd44780-uss720.o hd44780-hd44780-usbtiny.o hd44780-hd44780-usb4all.o hd44780-hd44780-ftdi.o hd44780-hd44780-ethlcd.o hd44780-hd44780-i2c.o -lusb -lftdi -lusb libbignum.a -ldl gcc: error: libbignum.a: No such file or directory make[3]: *** [hd44780.so] Error 1 make[3]: Leaving directory `/home/pterjan/rpmbuild/BUILD/lcdproc-0.5.6/server/drivers' So in the Makefile in server/drivers, hd44780.so needs to depend on libbignum.a hd44780_LDADD = libLCD.a @HD44780_DRIVERS@ @LIBUSB_LIBS@ @LIBFTDI_LIBS@ libbignum.a hd44780_DEPENDENCIES = @HD44780_DRIVERS@ so, i should move it to dependencies instead of ldadd in the Makefile.am and use autoreconf -i instead... but... this isn't the only driver, does this mean i'll have to change dependencies for almost all these drivers? I don't know if they use the lib :) there are at 20ish or more of them that have that exact library in their respective ldadd... i was hoping to have a easier way to make that library built before these drivers...
Re: [Mageia-dev] Status note
Op zaterdag 26 januari 2013 12:20:48 schreef Sandro CAZZANIGA: Le 26/01/2013 12:19, Pierre-Malo Deniélou a écrit : On 26/01/13 05:58, Joseph Wang wrote: I've been avoiding checking anything into the tree so as not to interfere with the Mageia 3 release. But I've been quite busy at working on various projects to be checked in as so as Cauldron opens up. Most of them involve somewhat more than packaging since I've been sending patches upstream The things that I've been working on are: 1) Cinnamon environment. I not only have a cinnamon environment working on my local box, but I've also created a set of packages that pull in all of the latest cinnamon themes, applets, and desklets. Really good! Will this be in Mageia 3? :) no, he said for Cauldron after Mageia 3 release. (unless backport, but cinnamon is not a leaf package, so not there either). you'll have to wait for at least Mageia 4 ( that is IF this package plays well with gnome and there's maintenance and such)
Re: [Mageia-dev] Status note
The cinnamon conflict with gnome has been fixed in the packages I have. There is a patch that fixes the problem that I've sent upstream, and I can package it locally with the patch. iinm you're still a novice packager, so ideally this should be doublechecked by others(mentor) and since you might have conflicts, there should at least be approval by the gnome packager... but well, we have some time for that anyway, since cauldron only reopens in april. As far as the other packages peazip - I'm looking at getting that packaged. It's pascal code, but it open source pascal code that doesn't look too bad. energytycoon - working on that openra - the problem with openra is that it seems to require closed source data files. That doesn't keep us from putting it into tainted, but it does put it on much lower priority. lgeneral also has that problem tainted is for patented packages. nonfree is for nonfree packages, or if they require nonfree files. I've looked over the package requests. I just submitted a few Chinese fonts. Mplayer2 looks interesting. in the mean time while cauldron is version frozen. perhaps you can also help to fix some of the bugs (especially if they are release critical) also, keep in mind that new packagers are great, but even those need to be maintained (of course, this only is for full packagers, but you can ask your mentor to maintain them in your place and when you become full packager to shift them to you).
Re: [Mageia-dev] URGENT: FOSDEM restaurant [input needed from everyone]
On 24/01/13 00:23, AL13N wrote: This time, i had actually tried to find an option to use a good caterer i know well, but location proves a big issue, most places i checked didn't allow external catering... :-( or the price had to be right... Indeed. The other suggestion would be to bet a lot of Belgian beers, then nobody will pay attention any more to the food :) that is nice! another solution is to move FOSDEM nearer to hotel/restaurants with good food :-)
Re: [Mageia-dev] URGENT: FOSDEM restaurant [input needed from everyone]
2013/1/24 Oliver Burger oliver@gmail.com: Am 24.01.2013 01:11, schrieb eatdirt: Indeed. The other suggestion would be to bet a lot of Belgian beers, That's an option for after dinner :D See you next week for some talking and Belgian beers... I had no objections against the restaurant and the dinner in 2011. Location, food drinks were ok. I did not hear or read negative reviews, although I don't know what happened when the drinking started after Oliver and I left. i had some negative comment, but looking back now (especially after the difference with 2012)... it might not have been that bad. the problem here is that i almost never go into the brussels region, and i was of the opinion that belgian food was the best of the world. i guess i need to exclude the brussels region from that. it's just stupid that due to location, we're forced to eat expensive and not the best-of-the-world food...
[Mageia-dev] URGENT: FOSDEM restaurant [input needed from everyone]
I'm sorry, i have sort of forgotten to get the restaurant, i've tried reserving in 3 random restaurants, i would like to ask what order you prefer the ones listed: see https://wiki.mageia.org/en/Fosdem_2013#Dinner_Saturday_night i can try to look for others, but i need feedback ASAP.
Re: [Mageia-dev] URGENT: FOSDEM restaurant [input needed from everyone]
Le 23/01/2013 13:42, AL13N a écrit : I'm sorry, i have sort of forgotten to get the restaurant, i've tried reserving in 3 random restaurants, i would like to ask what order you prefer the ones listed: see https://wiki.mageia.org/en/Fosdem_2013#Dinner_Saturday_night i can try to look for others, but i need feedback ASAP. We have some recommanded addresses. We will book it tomorrow I guess waiting for late registration on the wiki. BTW we have some specific requires from coling for it ;) sorry, i figured i was supposed to do it like last time, i'll clear the wiki again. I hope you can do better than what i got last year :-)
Re: [Mageia-dev] URGENT: FOSDEM restaurant [input needed from everyone]
Op woensdag 23 januari 2013 21:25:16 schreef eatdirt: On 23/01/13 14:01, AL13N wrote: sorry, i figured i was supposed to do it like last time, i'll clear the wiki again. I hope you can do better than what i got last year :-) Hey buffoon !!! :) you mean like *I did* last time, right :) I reckon it was a bit shit but that's difficult to fit 25 nerds + 1 veg in a room ; very true. This time, i had actually tried to find an option to use a good caterer i know well, but location proves a big issue, most places i checked didn't allow external catering... :-( or the price had to be right... Looking forward to see you soon my dear! Cheers, Chris.
[Mageia-dev] radeon opensource driver chooses 640x480
after complete update, it seems due to plymouth working, it chooses the first mode from HDMI probe (which seems to be 640x480 (the resolution plymouth ran on?), right before 1920x1080.) the old log file has 1920x1080 as first mode. atm, i set xorg.conf fixed on full HD resolution.
[Mageia-dev] pulseaudio multicast RTP sound sharing
after updates, it failed to work. even thought the devices exist and it's being sent that way, the volume on the sender is there, and the volume on the receiver is 0.
Re: [Mageia-dev] [RPM Groups] Final Final change for Mageia 3
Is there a way to list all packages violating these? since the mass rebuild is done, i would think that the previous changes are now enforced. the list for these should be small. so, a list+maintainer could be nice Op zondag 20 januari 2013 21:23:55 schreef Pierre-Malo Deniélou: Dear Packagers, I lay before you a last (I promise) change for the rpm groups. It affect packages currently in System, and it is done so that there is no cost in terms of new strings (since we are in freeze). - System/Configuration/Boot and Init renamed as System/Boot and Init - System/Configuration/Hardware disappears - System/Configuration/Networking renamed as System/Networking - System/Configuration/Other disappears - System/Configuration/Packaging renamed as System/Packaging - System/Configuration/Printing disappears For the groups that are disappearing, the packages can be easily spread among the System subgroups: - System/Base - System/Boot and Init - System/Cluster - System/Configuration - System/Fonts - System/Internationalization - System/Kernel and hardware - System/Libraries - System/Networking - System/Packaging - System/Printing - System/Servers - System/X11 I remind you that the policy is at: https://wiki.mageia.org/en/RPM_groups_policy#List_of_official_groups Thanks a lot !
Re: [Mageia-dev] What's the point of the latest nvidia update?
Op zondag 20 januari 2013 23:50:16 schreef Thomas Backlund: Robert Wood skrev 20.1.2013 23:16: So you're saying that because v295 has been out a while you feel it's stable so you're happy to have that in the official repositories? I can kind of understand that, although in the case of nvidia you'd think they had already done the bug fixing. If that ever would be true... many times when they add support for new hardware, old support gets either broken or dropped... for example going past 304.x to 310.x or higher drops hardware support for older hw. Anyway, in the case of the latest nvidia version it certainly does have new features, because it supports newer cards. In this case, it's not a big thing because it's relatively easy for me to install, but I would think that for new users who have modern software you'd really want them to have access to it. After all M2 is the latest stable release. But yes, this is a thing we need to improve... without breaking anything in the process... The best way for now to get newer drivers is to rebuild the srpm in cauldron and install that. and soonish, we could have (supported) backports, so that people needing/wanting this can have this one, while the people with older hardware can keep their things working.
Re: [Mageia-dev] What's the point of the latest nvidia update?
Op zaterdag 19 januari 2013 10:51:21 schreef Robert Wood: I have a modern nvidia graphics card on my desktop that necessittated having to get the very latest nvidia driver from the nvidia site and manually install. So, when we had a nvidia pakcage update on my laptop, I thought I'd give the Mageia package another go, but it makes sack-all difference, it still just sits there doing nothing and says: Failed to start Wait for Plymouth Boot Screen to Quit So I went and looked on my laptop and it looks like it's v 295.49 whereas the very latest version is 304.43. I need this for my modern graphics card or the desktop refuses to boot. So, why bother with v295.49 when there's a much more modern one? ** for mga2, the driver update (meaning no new functionality, just bugfixes is 295) for mga3 (beta1) the latest driver is atm 310... if for mga2 you want a newer driver you should ask for a backport request, ie: to have 310 on mga2 as well. plz file such requests at https://bugs.mageia.org/
Re: [Mageia-dev] php packages failing to build
Is anything used by something else? Do most of them have replacements or are obsoleted by others? php-bcompiler ... iirc, i donno if there is a replacement for this php-archive ... sounds like it's obsoleted by others php-xslcache ... is this obsolete too? php-gtk2 ... is there a php-gtk3 php-tdb ... this might be used for samba stuff and: php-perl php-python --- WTF? Op zaterdag 19 januari 2013 09:26:35 schreef Thomas Spuhler: The following packages don't build anymore. The php-5.4(zend) patches have been applied, but there are a lot of other issues. All of them haven't seen any upstream activities fir 2 years. I propose to move them to obsoletes if nobody complains or steps I will do it early next week: php-archive php-bcompiler php-colorer php-courierauth php-ecasound php-event php-filepro php-framegrab php-funcall php-gtk2 php-mcache php-mnogosearch php-perl php-ps php-python php-syck php-tcpwrap php-tdb php-teng php-tk php-xslcache php-yp
Re: [Mageia-dev] What's the point of the latest nvidia update?
Op zaterdag 19 januari 2013 17:59:32 schreef Claire Robinson: On 19/01/13 17:52, Juan Luis Baptiste wrote: On Sat, Jan 19, 2013 at 9:44 AM, AL13N al...@rmail.be wrote: if for mga2 you want a newer driver you should ask for a backport request, ie: to have 310 on mga2 as well. plz file such requests at https://bugs.mageia.org/ This means that backports at last are opened ?? http://is.gd/RPG8NO this blocks backports, but this has been decided to fix soon-ish. so, soon backports is opened (hopefully), but perhaps sooner if there are more backport requests. be advised that asking for a backport means you in combination with maintainer will have make sure you have at least 2 people (i586/x86_64) who can QA test it for QA validation. (since we could use more help on QA when we're opening backports). i think your request is a sensible one and hope you're willing to help out to get it into mga2. I would advise you if you find those people to state so in the bug report. The, hopefully that bug will be finished and backports will be opened.
Re: [Mageia-dev] how to NFS+PXE
Op zondag 6 januari 2013 23:54:22 schreef AL13N: Op vrijdag 4 januari 2013 10:08:04 schreef AL13N: Op donderdag 3 januari 2013 22:14:51 schreef AL13N: [...] just a reply to note that /dev/dvd does not exist, making playing DVDs in media players not working: []# ln -s /dev/sr0 /dev/dvd i am unsure of course if this link will be there next time? is /dev on tmpfs? did i forgot to install some packages that have udev rules in it? or is there something more going on? i do remember even going to deviceinfo in MCC, so... i would expect that at least to tell me what would need to be installed...
Re: [Mageia-dev] [changelog] [RPM] cauldron core/release xen-4.2.1-2.mga3
Op vrijdag 18 januari 2013 17:14:28 schreef Thierry Vignaud: On 16 January 2013 21:02, AL13N al...@rmail.be wrote: i was planning on removing xm and xend support. perhaps closer should be to find out what libvirtd isn't working? of course, i did ask to maintain this, but it isn't easy for me to actually test it :-(. i had planned to test this at work, but other work has made me unable to actually run it for a while... anyway, i had to patch some stuff about xenconsole, but maybe i should take a closer look into what other patches fedora has. well, i should at least try to find some hardware i can use for this. also, i had planned on dropping internal qemu, but it upstream told me to wait for the next major version. if anyone can help me out with xen, i'd appreciate it. @tv: - did you manually make another boot entry in grub with the hypervisor as kernel and the kernel as module and the initrd as another module? (that is necessary) no since that's automatic with grub2 - could you check if the xl command does work? xl list works but not libvirt users - could you possibly give logs for libvirtd (and maybe do: 'systemctl list- units' ?) thanks a bunch [root@localhost ~]# service libvirtd status Redirecting to /bin/systemctl status libvirtd.service libvirtd.service - Virtualization daemon Loaded: loaded (/usr/lib/systemd/system/libvirtd.service; enabled) Active: active (running) since Fri, 2013-01-18 16:56:53 CET; 12min ago Main PID: 867 (libvirtd) CGroup: name=systemd:/system/libvirtd.service ├ 867 /usr/sbin/libvirtd └ 1214 dnsmasq --conf-file=/var/lib/libvirt/dnsmasq/default.conf Jan 18 17:01:28 localhost libvirtd[867]: Unable to issue hypervisor ioctl 3166208: Permission non accordée Jan 18 17:01:28 localhost libvirtd[867]: Unable to issue hypervisor ioctl 3166208: Permission non accordée Jan 18 17:01:28 localhost libvirtd[867]: Unable to issue hypervisor ioctl 3166208: Permission non accordée Jan 18 17:01:28 localhost libvirtd[867]: Unable to issue hypervisor ioctl 3166208: Permission non accordée Jan 18 17:01:28 localhost libvirtd[867]: erreur interne impossible de se connecter à Xen Jan 18 17:01:28 localhost libvirtd[867]: unable to connect to 'localhost:8000': Connexion refusée Jan 18 17:01:58 localhost libvirtd[867]: No response from client 0x8ec290 after 5 keepalive messages in ...conds Jan 18 17:04:53 localhost libvirtd[867]: erreur interne impossible de se connecter à Xen Jan 18 17:04:53 localhost libvirtd[867]: unable to connect to 'localhost:8000': Connexion refusée Jan 18 17:04:53 localhost libvirtd[867]: End of file while reading data: Erreur d'entrée/sortie # systemctl list-units|grep xen [..] perhaps libvirtd cannot connect because of some kind of thing not being being enabled... i would like to see more of the libvirtd log, from the beginning... it seems like there's more earlier logs. also, perhaps libvirtd might be trying to connect to the server as if it were a kvm server... so need more logs and possibly config files. with xl, can you actually start a VM (para/hvm), that you can get into with the xenconsole? I might soon get a test system meant for virtualisation for personal use later... i plan on doing a complete test with it. and try to enable kvm and xen at the same time /o\ if that would be possible... (i doubt it)
Re: [Mageia-dev] [changelog] [RPM] cauldron core/release xen-4.2.1-2.mga3
Op woensdag 16 januari 2013 10:06:19 schreef Colin Guthrie: 'Twas brillig, and Colin Guthrie at 16/01/13 09:53 did gyre and gimble: Cool, so I had this still on my list to check. Seems the fix (which was just ghosting the files) wasn't correct and as I mentioned in a previous mail about tmpfiles stuff, it would be wise to check the Xen package to see what was done about adding tmpfiles support. AL13n reckoned that fedora just ghosted the files, but on closer inspection they do also add tmpfiles support... http://pkgs.fedoraproject.org/cgit/xen.git/tree/tmpfiles.d.xen.conf I'll fix it up. Should be fixed by: http://svnweb.mageia.org/packages?view=revisionrevision=388627 (assuming that the error really was about that file :D) Col i kind of doubt it, it looks more like xc isn't available (xenconsole?) (thanks anyway, colin :-) ) btw: @tv, any reason why you're using xend? the xl toolchain doesn't require xend at all. i was planning on removing xm and xend support. perhaps closer should be to find out what libvirtd isn't working? of course, i did ask to maintain this, but it isn't easy for me to actually test it :-(. i had planned to test this at work, but other work has made me unable to actually run it for a while... anyway, i had to patch some stuff about xenconsole, but maybe i should take a closer look into what other patches fedora has. well, i should at least try to find some hardware i can use for this. also, i had planned on dropping internal qemu, but it upstream told me to wait for the next major version. if anyone can help me out with xen, i'd appreciate it. @tv: - did you manually make another boot entry in grub with the hypervisor as kernel and the kernel as module and the initrd as another module? (that is necessary) - could you check if the xl command does work? - could you possibly give logs for libvirtd (and maybe do: 'systemctl list- units' ?) thanks a bunch
Re: [Mageia-dev] Features
Op woensdag 16 januari 2013 17:43:36 schreef Thomas Backlund: Colin Guthrie skrev 16.1.2013 17:34: 'Twas brillig, and mustafaa1...@yahoo.com at 16/01/13 15:18 did gyre and gimble: On Tuesday, January 15, 2013 05:56:34 PM Mustafa Muhammad wrote: On 01/15/2013 03:42 PM, Thomas Backlund wrote: Mustafaa Al-Hamdaani skrev 15.1.2013 14:35: Hi, Are features still accepted for Mageia 3? I have these three: 1) Enable vertical two finger scrolling by default, simple but important. 2) Desktop greeter (like kaptan of pardus or its fork for Chakra, kapudan): http://www.chakra-linux.org/wiki/index.php/Kapudan 3) catalyst-legacy for AMD cards 4xxx and before. This one depends on AMD. They have not released any legacy driver since 12.6 last summer, and that is not supporting x11-server 1.13 we use. I know, I just hoped we can ship x11-server 1.12 and 1.13 and only one of them is installed, the power consumption with the open source drivers is just insane, especially for a laptop (and the quality too). I asked yesterday and the answer was too late, but if this is technically possible, I think it will make a huge difference for a big number of Mageia users, maybe 25% of all users use those AMD cards, so please would you reconsider shipping catalyst-legacy if it is technically feasible. For such a benefit for the community, I think it worth considering (from catalyst maintainer and others). Being realistic, shipping two x servers is simply not going to happen in time. or ever... It'll need lots of extra work including more h/w detection and automatic installation of the legacy x server (assuming the user wants the proprietary drivers only, the free drivers will of course want the latest xserver instead). I feel it's just too much complication at this late stage to do this. There is way too much stuff integrated / interacting with x11-server, to sanely provide 2 of them without introducing regressions on either side... Perhaps someone can do some clever edits on the binaries to make them work with the newer xserver... Nope. No can do... that would violate the license. it's sad, i too have one that's just not supported by AMD anymore, but that's simply the way it is... AMD doesn't think 3y old hardware needs to be supported, you need to buy new stuff instead... :-( i found it annoying, but ah well, i'm just running it with open source driver on my media center, and at least the video performence is adequate...
Re: [Mageia-dev] Unable to complete update rtkit package and system failure
Op donderdag 17 januari 2013 01:23:12 schreef Kira: 在 Thu, 17 Jan 2013 00:49:01 +0800, Johnny A. Solbu coo...@solbu.net寫道: On Wednesday 16. January 2013 16.29, Kira wrote: Today I use the power button to force shutdown and boot, I used to do that too, untill I stumbled across a tip about the SysRq key. http://en.wikipedia.org/wiki/Magic_SysRq_key#Uses Now I only use the power button when the SysRq sequence ain't working. In my cases, all system hotkey don't work. I have tried Ctrl+Alt+Backspace. X won't restart. Maybe this should be noted with further testing. iinm Ctrl+Alt+Backspace is now disabled by default in X? in any case SysReq keys are quite different, they work directly in kernel, so you could try that...
Re: [Mageia-dev] Missign rebuilds tagged mga1
Op dinsdag 15 januari 2013 12:32:27 schreef Johnny A. Solbu: On Tuesday 15. January 2013 11.43, Colin Guthrie wrote: Sounds like one of your media couldn't be updated or something. Not directly related to urpmi-proxy per-se but it could certainly confuse the issue :) Just for good measure, I ran «urpmi.upfdate -a» just now, and the count didnt change. No media where unable to update, and I only have one repo configured. (http://ftp-stud.hs-esslingen.de/pub/Mirrors) just mentioning, that the disadvantage to urpmi-proxy, is that it hides connection errors to repositories, since it will use cache if it fails. you can look at the logfile if it mentions HIT_AFTER_FAIL (which means it gets you cache after it failed) lately, i've been testing with 2 repositories and changing the timeout value to very low values (5s) as first repos, i choose one that is fast, and as second repos, i use what is always up2date. considering MD5SUM would be asked for both repositories (it's a specially configured file for that), it would get you always up2date results, since the first would fail to have the file and the second one would be asked for it. for me, this gave alot better results especially for cauldron during the mass rebuild...
Re: [Mageia-dev] Missign rebuilds tagged mga1
Op woensdag 16 januari 2013 21:22:22 schreef Colin Guthrie: 'Twas brillig, and AL13N at 16/01/13 20:22 did gyre and gimble: Op dinsdag 15 januari 2013 12:32:27 schreef Johnny A. Solbu: On Tuesday 15. January 2013 11.43, Colin Guthrie wrote: Sounds like one of your media couldn't be updated or something. Not directly related to urpmi-proxy per-se but it could certainly confuse the issue :) Just for good measure, I ran «urpmi.upfdate -a» just now, and the count didnt change. No media where unable to update, and I only have one repo configured. (http://ftp-stud.hs-esslingen.de/pub/Mirrors) just mentioning, that the disadvantage to urpmi-proxy, is that it hides connection errors to repositories, since it will use cache if it fails. you can look at the logfile if it mentions HIT_AFTER_FAIL (which means it gets you cache after it failed) lately, i've been testing with 2 repositories and changing the timeout value to very low values (5s) as first repos, i choose one that is fast, and as second repos, i use what is always up2date. considering MD5SUM would be asked for both repositories (it's a specially configured file for that), it would get you always up2date results, since the first would fail to have the file and the second one would be asked for it. for me, this gave alot better results especially for cauldron during the mass rebuild... Interesting idea. Never thought about using two mirrors in the config. I fought with urpmi-proxy today for a while. No matter what I tried, when downloading a synthesis via the proxy it always ended up too small and with md5sum failures. Requesting the same file direct from the mirrors worked every time. I noticed that the file never ended up in the cache tree, just in the tmp dir. Time wasn't on my side, so I didn't debug further... one to fight another day. (this is with urpmi-proxy-0.3.2-1.mga2 on mga2 FWIW) Col so, either a partial file, or out of disk space? better make sure the cache tree is the same partition as the tmp dir it uses. in any case, using multiple mirrors isn't supported... (yet) i'm just trying them out this way. i had alot of troubles with cauldron due to mismatches with MD5SUM and the synthesis files, because the MD5SUM doesn't match the synthesis files but, sometimes, i do have some oddness in files (i think maybe i need better error-checking) like if you get a partial result, it doesn't get removed from cache. so if it does fail, i delete the file from the cache tree for now. don't forget to do that in all your cascading urpmi-proxy's... i actually have tested 3 cascading urpmi-proxy's. in normal usage, i have an urpmi-proxy at my local lan. one at my desktop itself, and then once i tested urpmi-proxy in a VM on my desktop. the one on my desktop has an extra repository (and changes which ones are default), and the one on the server has now 2 sources (http mirrors), with very small timeouts (i may have used 3 or 5 seconds) since i have an urpmi-proxy at work, my work-laptop had always 2 sources which i uncommented constantly, but perhaps i should actually set them both, with very small timeouts... maybe with a 3rd slow one? /me continues to ponder
Re: [Mageia-dev] Missign rebuilds tagged mga1
Op woensdag 16 januari 2013 22:33:10 schreef Johnny A. Solbu: On Wednesday 16. January 2013 21.22, AL13N wrote: you can look at the logfile if it mentions HIT_AFTER_FAIL (which means it gets you cache after it failed) # grep -i HIT_AFTER_FAIL /var/log/urpmi-proxy.log |wc -l 0 So that's not the issue. :-)= then it looks like you're up2date after all...
Re: [Mageia-dev] Help needed: rpmlint checks not working
Op zondag 13 januari 2013 13:26:51 schreef Colin Guthrie: [...] Ghosting achieves very little in this case. Does xen automatically create those directories happily without the need for tmpfiles? If so I'd personally not package them at all (as it just continues to show up in the list generated by the urpmf command listed earlier as a false positive). While ghosting does have the advantage that rpm -qf will return sort of valid results, it does make this transition period more difficult as it would mean our list of packages would never get smaller. I'm also not totally convinced that the rpm -qf use case is benefitial enough to keep package %files+%ghosts synced with tmpfiles contents, especially as the tmpfiles become part of the upstream package. If it could somehow become automated (i.e. via a packaging script) then I'd be happy to support that. So, question. Does xen actually work? There appears to be no tmpfiles in it and thus I don't see what creates those folders unless xen does it internally (i.e. like gdm does). Can you confirm it's OK without tmpfiles and I'll manually filter it out of my urpmf command. If you also feel there is no real point in ghosting here specifically and not in any of the other packages, please do remove the ghosts as it'll save that manual filtering. thanks, i'll take this under advisement
Re: [Mageia-dev] The upcomming MSN network shutdown is postponed
Op zaterdag 12 januari 2013 11:23:05 schreef Sander Lepik: 12.01.2013 10:05, AL13N kirjutas: We should drop all msn related things right now, just in case it's all shut down. We have no reason to drop them just yet. They will work another year. Who knows, maybe even more. i guess you didn't see the sarcasm...
Re: [Mageia-dev] Help needed: rpmlint checks not working
Op zaterdag 12 januari 2013 16:43:09 schreef Colin Guthrie: [..] There are currently ~70 ish packages to fix. I'll fix them up, but help is welcome :) [...] Then there are the udev rules :) [...] I will do all of these but as I've said already, people are more than welcome to fix some up :D Col i'll try and fix xen for both
Re: [Mageia-dev] Help needed: rpmlint checks not working
Op zaterdag 12 januari 2013 18:20:25 schreef Colin Guthrie:
'Twas brillig, and Johnny A. Solbu at 12/01/13 17:29 did gyre and gimble:
On Saturday 12. January 2013 17.43, Colin Guthrie wrote:
I will do all of these but as I've said already, people are more than
welcome to fix some up :D
As I'm the maintainer of radvd I can try and fix that one. :-)=
But just so I understand this: We should replace e.g
«%{buildroot}%{_localstatedir}/run/blahblah» with
«%{buildroot}/run/blahblah» ?
Or is there another rpm variable I should use?
https://wiki.mageia.org/en/System_Service_policy
:)
Col
what wiki page deals with the udev part?
Re: [Mageia-dev] Help needed: rpmlint checks not working
Op zaterdag 12 januari 2013 22:24:35 schreef AL13N: Op zaterdag 12 januari 2013 16:43:09 schreef Colin Guthrie: [..] There are currently ~70 ish packages to fix. I'll fix them up, but help is welcome :) [...] Then there are the udev rules :) [...] I will do all of these but as I've said already, people are more than welcome to fix some up :D Col i'll try and fix xen for both it seems for xen, it doesn't seem so standard. fedora ghosted those 3, so i did that too. no idea what to do with the udev parts, what is wrong with it?
Re: [Mageia-dev] Why no totem-plugin-arte in Mageia ?
Op vrijdag 11 januari 2013 09:50:46 schreef Götz Waschk: the new version of totem-plugin-arte was uploaded to cauldron, please test it. Finaly I could try it. Sound was missing because gstreamer1.0-faad was not installed. Maybe totem-plugin-arte should also go to tainted media, and require faad? Hi, I'm answering to the dev list, I hope this is OK. You are right, the faad support is required. I don't know how to move packages, can someone help? Regards, Götz maybe it should be built without like now, and additionally also with faad support in tainted
Re: [Mageia-dev] /usr/bin/file broken on cauldron
Op donderdag 10 januari 2013 17:20:04 schreef David Walser: Pascal Terjan pterjan@... writes: On Thu, Jan 10, 2013 at 3:51 PM, Pascal Terjan pterjan@... wrote: This is fixed in git but I couldn't find the specific commit The fix is https://github.com/glensc/file/commit/834831f53398cf2a1cfcd1daaf88c437bbf8d2 1f Fixed in file-5.12-6.mga3, but this is a bit more interesting... If you actually look at that commit, you see: -# $File: assembler,v 1.1 2011/12/08 12:12:46 rrt Exp $ +# $File: assembler,v 1.2 2012/10/31 18:41:42 christos Exp $ But the file in the tarball already reflects the v 1.2 christos (who is the one who made this commit), while the rest of the contents of that file reflect the previous version, aka the rest of that commit isn't applied in the tarball. Anyway, I verified that fixing this fixes the detection for /usr/bin/automake. that's bad practice
Re: [Mageia-dev] Minimal mageia install
Op maandag 7 januari 2013 15:39:30 schreef Eatdirt: On 10/23/2012 02:53 PM, Bruno Cornec wrote: Helo, I'm in the process of redeploying automatically my firewall machine, using Mageia. For that I'd like to have a very minimal install. However, I'm ending up with 580 packages, among them a lot of X11 content, whereas I want a text base install only. +1 I agree with this, we have some bugs in package dependencies. Please, don't hesitate to report them on bugzilla for the next bugfest! We should also try to fix them. I reported this one months ago, Colin :))) https://bugs.mageia.org/show_bug.cgi?id=7960 Cheers, Chris. i'm always up for lowering the minimum install. a while ago, i did some work on that, but they are not easy. in particular the X libs are pretty difficult to get out. some of it is due to some drak tools being required by stuff and requiring some other stuff. it does mean that for instance some code will need to have some functions split off into another class or something... iinm (but this is all quite a while back, i'd need to check more on that)
Re: [Mageia-dev] Minimal mageia install
Op maandag 7 januari 2013 00:53:05 schreef Bruno Cornec: [...] Ok so it's now available at https://wiki.mageia.org/en/Auto_inst with an addition and s/Mandriva/Mageia/ done. [...]this is nice!
Re: [Mageia-dev] Packages backlog
Op zondag 6 januari 2013 23:30:34 schreef Pierre-Malo Deniélou: Le 06/01/13 23:03,Joseph Wang nous adresse ces quelques mots : [...] vstar I just looked at vstar. I have several remarks or comments: - there is a typo in the URL - Usually it's better not to have a weird downloading script in SOURCES for svn revisions, but to put it as a comment in the SPEC file. == be advised that the build system does NOT have internet access and cannot fetch anything. i too in my packages had to remove those parts. - BTW, why can't you use the stable version instead of the svn release? There is a very recent one at http://sourceforge.net/projects/vstar/files/2.14.2/ If you use that one, you can just put as Source0 the sourceforge URL to the archive - your desktop file does not mention an icon, which makes for an blank entry in the menu. If you fix these things, I happy to submit it. Cheers,
Re: [Mageia-dev] RPM group change before Beta 2
Op zondag 6 januari 2013 23:24:34 schreef Pierre-Malo Deniélou: Le 06/01/13 23:22,Joseph Wang nous adresse ces quelques mots : Sure thing. I can start patching some of the rpms that aren't haven't been done yet. However, I was wondering if I can do that with just subversion commit privileges or do I need to be able to submit build requests to do this? To patch, you do not need to submit. But it's good practice to contact the maintainer when you do that: IRC is a fast way to do that. Cheers, in particular, on #mageia-dev the Sophie bot can tell you which maintainer is from which package by: :maint package also, if it tells nobody, you can still see who last Packaged it with mgarepo log package or on irc with :p -s package
Re: [Mageia-dev] PXE boot on cauldron failed
Op maandag 7 januari 2013 12:18:05 schreef Olivier Thauvin: Hello, We use PXE to install computers, it works very fine for Mageia 2 but it failed with Cauldron with same parameters: LABEL manual64bits KERNEL http://distrib-coffee.ipsl.jussieu.fr/pub/linux/Mageia/distrib/2/x86_64/iso linux/alt0/vmlinuz APPEND initrd=http://distrib-coffee.ipsl.jussieu.fr/pub/linux/Mageia/distrib/2/x86 _64/isolinux/alt0/all.rdz automatic=method:http,ser:distrib-coffee.ipsl.jussieu.fr,dir:/pub/linux/Mag eia/distrib/2/x86_64/,int:eth0,netw:dhcp vga=788 and for cauldron: LABEL manual64bits KERNEL http://distrib-coffee.ipsl.jussieu.fr/pub/linux/Mageia/distrib/cauldron/x86 _64/isolinux/alt0/vmlinuz APPEND initrd=http://distrib-coffee.ipsl.jussieu.fr/pub/linux/Mageia/distrib/cauld ron/x86_64/isolinux/alt0/all.rdz automatic=method:http,ser:distrib-coffee.ipsl.jussieu.fr,dir:/pub/linux/Mag eia/distrib/cauldron/x86_64/,int:eth0,netw:dhcp vga=788 I can see the end of kernel messages but I cannot see the first message... Any idea ? huh, i never knew that you could specify URLs in pxe configs... for kernel and initrds
