From lukaszgl at post.pl Mon Feb 11 21:24:24 2013 From: lukaszgl at post.pl (Lukasz Glebicki) Date: Mon, 11 Feb 2013 21:24:24 +0100 Subject: [TH - 64] Chromium chromoli po upgrade In-Reply-To: <201211300954.20652@laptok.ed.pl> References: <50B7DC6B.1020005@o2.pl> <50B8730A.2000600@sojka.co> <201211300954.20652@laptok.ed.pl> Message-ID: <3330068.pSP6KcgNKF@inhell> On Friday 30 of November 2012 09:54:20 ?ukasz Ma?ko wrote: > Dnia pi?tek, 30 listopada 2012, Grzegorz S?jka napisa?: > > U mnie chromium-browser-23.0.1271.64-3.x86_64 te? si? wywraca. Na dw?ch > > r??nych maszynach x86_64 te same objawy. Pojawia si? okno ale zamiast > > strony startowej na ?rodku jest smutna mordka i komentarz, ?e co? posz?o > > nie tak. Dmesg wywala: > > > > [ 282.276966] chromium-browse[2097]: segfault at 122 ip > > 00007fafd200d713 sp 00007fafb7372370 error 6 in > > chromium-browser[7fafd11d3000+3d17000] > > [ 294.557690] chromium-browse[2119]: segfault at 122 ip > > 00007fafd200d713 sp 00007fafb7372370 error 6 in > > chromium-browser[7fafd11d3000+3d17000] > > Czy?by pierwszy raz od dawna, ?e i686 jest OK a na x86_64 nie? Hello, Topic taken from users-pl, which describe unusable cb since version 23. The problem with chromium-browser occurs with seccomp-filter. Running chromium with --disable-seccomp-filter-sandbox is a workaround. Google took me to: http://code.google.com/p/chromium/issues/detail?id=149834 and then to http://src.chromium.org/viewvc/chrome/branches/1271/src/content/common/sandbox_seccomp_bpf_linux.cc?r1=162147&r2=162146&pathrev=162147 http://src.chromium.org/viewvc/chrome/trunk/src/content/browser/renderer_host/render_process_host_impl.cc?r1=140792&r2=140875&pathrev=140875 It seems that source has this patch, but it doesn't work. Any ideas? Kind Regards, -- ?ukasz G??bicki mail/rot13:yhxnfmty at cbfg.cy PLD/Linux Team gg:246267 Linux Registered User #318551 blekot:{irc,skype} From glen at pld-linux.org Tue Feb 12 10:52:23 2013 From: glen at pld-linux.org (=?UTF-8?B?RWxhbiBSdXVzYW3DpGU=?=) Date: Tue, 12 Feb 2013 11:52:23 +0200 Subject: [TH - 64] Chromium chromoli po upgrade In-Reply-To: <3330068.pSP6KcgNKF@inhell> References: <50B7DC6B.1020005@o2.pl> <50B8730A.2000600@sojka.co> <201211300954.20652@laptok.ed.pl> <3330068.pSP6KcgNKF@inhell> Message-ID: <511A10D7.8060400@pld-linux.org> On 11.02.2013 22:24, Lukasz Glebicki wrote: > Any ideas? use kernel-longterm (3.4) until then. i tried to reproduce it in virtualbox-i686 3.7.x kernel, and it did not occour there, perhaps it's also related to video driver? or it's x86-64 specific? what does your chrome://sandbox/ say on the crashing system? for me system where x86-64 3.7.x give oops page, with 3.4 kernel same chromium gives: Sandbox Status SUID Sandbox Yes PID namespaces Yes Network namespaces Yes Seccomp-legacy sandbox No Seccomp-BPF sandbox No You are adequately sandboxed. -- glen From glen at pld-linux.org Tue Feb 12 10:56:59 2013 From: glen at pld-linux.org (=?UTF-8?B?RWxhbiBSdXVzYW3DpGU=?=) Date: Tue, 12 Feb 2013 11:56:59 +0200 Subject: [TH - 64] Chromium chromoli po upgrade In-Reply-To: <3330068.pSP6KcgNKF@inhell> References: <50B7DC6B.1020005@o2.pl> <50B8730A.2000600@sojka.co> <201211300954.20652@laptok.ed.pl> <3330068.pSP6KcgNKF@inhell> Message-ID: <511A11EB.1000905@pld-linux.org> On 11.02.2013 22:24, Lukasz Glebicki wrote: > It seems that source has this patch, but it doesn't work. what's your glibc version/arch and kernel version/arch? -- glen From lukaszgl at post.pl Tue Feb 12 10:59:32 2013 From: lukaszgl at post.pl (=?UTF-8?B?xYF1a2FzeiBHxYLEmWJpY2tp?=) Date: Tue, 12 Feb 2013 10:59:32 +0100 Subject: [TH - 64] Chromium chromoli po upgrade References: <50B7DC6B.1020005@o2.pl> <50B8730A.2000600@sojka.co><201211300954.20652@ laptok.ed.pl> <3330068.pSP6KcgNKF@inhell> Message-ID: <588b5a30846c93954823c88881cc9a2d.qmail@home.pl> Dnia 2013-02-12 10:57 Elan Ruusam?e napisa?(a): >On 11.02.2013 22:24, Lukasz Glebicki wrote: >> It seems that source has this patch, but it doesn't work. >what's your glibc version/arch and kernel version/arch? x86_64 and all packages from Th + ready are up to date. I don't have access to this machine right now. I'm using nVidia drivers. -- ?ukasz G??bicki From lukaszgl at post.pl Tue Feb 12 11:01:17 2013 From: lukaszgl at post.pl (=?UTF-8?B?xYF1a2FzeiBHxYLEmWJpY2tp?=) Date: Tue, 12 Feb 2013 11:01:17 +0100 Subject: [TH - 64] Chromium chromoli po upgrade References: <50B7DC6B.1020005@o2.pl> <50B8730A.2000600@sojka.co><201211300954.20652@ laptok.ed.pl> <3330068.pSP6KcgNKF@inhell> Message-ID: <449f97ed0310cee326213f21a09eb3e8.qmail@home.pl> Dnia 2013-02-12 10:52 Elan Ruusam?e napisa?(a): >On 11.02.2013 22:24, Lukasz Glebicki wrote: >> Any ideas? >use kernel-longterm (3.4) until then. > >i tried to reproduce it in virtualbox-i686 3.7.x kernel, and it did not >occour there, perhaps it's also related to video driver? or it's x86-64 >specific? what does your chrome://sandbox/ say on the crashing system? > >for me system where x86-64 3.7.x give oops page, with 3.4 kernel same >chromium gives: > > > Sandbox Status > >SUID Sandbox Yes > PID namespaces Yes > Network namespaces Yes >Seccomp-legacy sandbox No >Seccomp-BPF sandbox No > >You are adequately sandboxed. > > > > > > chrome://sandbox/ will not work when seccomp is not disabled because chromium is not able to show any page. Disabling seccomp is IMO better workaround than changing kernel, but I will try it. -- ?ukasz G??bicki From glen at pld-linux.org Tue Feb 12 11:23:27 2013 From: glen at pld-linux.org (=?UTF-8?B?RWxhbiBSdXVzYW3DpGU=?=) Date: Tue, 12 Feb 2013 12:23:27 +0200 Subject: [TH - 64] Chromium chromoli po upgrade In-Reply-To: <3330068.pSP6KcgNKF@inhell> References: <50B7DC6B.1020005@o2.pl> <50B8730A.2000600@sojka.co> <201211300954.20652@laptok.ed.pl> <3330068.pSP6KcgNKF@inhell> Message-ID: <511A181F.90108@pld-linux.org> On 11.02.2013 22:24, Lukasz Glebicki wrote: > On Friday 30 of November 2012 09:54:20 ?ukasz Ma?ko wrote: >> >Dnia pi?tek, 30 listopada 2012, Grzegorz S?jka napisa?: >>> > >U mnie chromium-browser-23.0.1271.64-3.x86_64 te? si? wywraca. Na dw?ch >>> > >r??nych maszynach x86_64 te same objawy. Pojawia si? okno ale zamiast >>> > >strony startowej na ?rodku jest smutna mordka i komentarz, ?e co? posz?o >>> > >nie tak. Dmesg wywala: >>> > > >>> > >[ 282.276966] chromium-browse[2097]: segfault at 122 ip >>> > >00007fafd200d713 sp 00007fafb7372370 error 6 in >>> > >chromium-browser[7fafd11d3000+3d17000] >>> > >[ 294.557690] chromium-browse[2119]: segfault at 122 ip >>> > >00007fafd200d713 sp 00007fafb7372370 error 6 in >>> > >chromium-browser[7fafd11d3000+3d17000] >> > >> >Czy?by pierwszy raz od dawna, ?e i686 jest OK a na x86_64 nie? > Hello, > Topic taken from users-pl, which describe unusable cb since version 23. > > The problem with chromium-browser occurs with seccomp-filter. > > Running chromium with --disable-seccomp-filter-sandbox is a workaround. > > Google took me to: > > http://code.google.com/p/chromium/issues/detail?id=149834 > > and then to > > http://src.chromium.org/viewvc/chrome/branches/1271/src/content/common/sandbox_seccomp_bpf_linux.cc?r1=162147&r2=162146&pathrev=162147 > http://src.chromium.org/viewvc/chrome/trunk/src/content/browser/renderer_host/render_process_host_impl.cc?r1=140792&r2=140875&pathrev=140875 > > It seems that source has this patch, but it doesn't work. > > Any ideas? as much i understood reading the bugreport then "segfault at NUMBER", means syscall NUMBER in HEX, the reports you referred had 0x19, but our (yours and mine) are 0x122 hex (290 dec) which is different syscall: Feb 11 19:38:59 blodnatt kernel: : [ 375.154516] chromium-browse[3544]: segfault at 122 ip 00007f3f9c5ea353 sp 00007f3f865e5330 error 6 in chromium-browser[7f3f9b794000+3e95000] Feb 11 19:39:00 blodnatt kernel: : [ 375.292081] chromium-browse[3551]: segfault at 122 ip 00007f3f9c5ea353 sp 00007f3f865e5330 error 6 in chromium-browser[7f3f9b794000+3e95000] Feb 11 19:39:00 blodnatt kernel: : [ 375.857206] chromium-browse[3563]: segfault at 122 ip 00007f3f9c5ea353 sp 00007f3f865e5330 error 6 in chromium-browser[7f3f9b794000+3e95000] Feb 11 19:39:00 blodnatt kernel: : [ 375.882080] chromium-browse[3568]: segfault at 122 ip 00007f3f9c5ea353 sp 00007f3f865e5330 error 6 in chromium-browser[7f3f9b794000+3e95000] Feb 11 19:39:00 blodnatt kernel: : [ 376.026527] chromium-browse[3573]: segfault at 122 ip 00007f3f9c5ea353 sp 00007f3f865e5330 error 6 in chromium-browser[7f3f9b794000+3e95000] Feb 11 19:39:00 blodnatt kernel: : [ 376.037300] chromium-browse[3578]: segfault at 122 ip 00007f3f9c5ea353 sp 00007f3f865e5330 error 6 in chromium-browser[7f3f9b794000+3e95000] Feb 11 19:39:00 blodnatt kernel: : [ 376.053965] chromium-browse[3583]: segfault at 122 ip 00007f3f9c5ea353 sp 00007f3f865e5330 error 6 in chromium-browser[7f3f9b794000+3e95000] Feb 11 19:39:00 blodnatt kernel: : [ 376.075011] chromium-browse[3588]: segfault at 122 ip 00007f3f9c5ea353 sp 00007f3f865e5330 error 6 in chromium-browser[7f3f9b794000+3e95000] Feb 11 19:39:00 blodnatt kernel: : [ 376.097798] chromium-browse[3593]: segfault at 122 ip 00007f3f9c5ea353 sp 00007f3f865e5330 error 6 in chromium-browser[7f3f9b794000+3e95000] Feb 11 19:39:14 blodnatt kernel: : [ 390.074960] chromium-browse[3648]: segfault at 122 ip 00007f3f9c5ea353 sp 00007f3f865e5330 error 6 in chromium-browser[7f3f9b794000+3e95000] Feb 11 19:39:15 blodnatt kernel: : [ 391.065551] chromium-browse[3653]: segfault at 122 ip 00007f3f9c5ea353 sp 00007f3f865e5330 error 6 in chromium-browser[7f3f9b794000+3e95000] Feb 11 19:39:16 blodnatt kernel: : [ 391.664702] chromium-browse[3658]: segfault at 122 ip 00007f3f9c5ea353 sp 00007f3f865e5330 error 6 in chromium-browser[7f3f9b794000+3e95000] Feb 11 19:39:25 blodnatt kernel: : [ 400.947865] chromium-browse[3664]: segfault at 122 ip 00007f3f9c5ea353 sp 00007f3f865e5330 error 6 in chromium-browser[7f3f9b794000+3e95000] Feb 11 19:39:30 blodnatt kernel: : [ 405.581665] chromium-browse[3716]: segfault at 122 ip 00007f8c747b4353 sp 00007f8c5e7af330 error 6 in chromium-browser[7f8c7395e000+3e95000] Feb 11 19:39:30 blodnatt kernel: : [ 405.588052] chromium-browse[3719]: segfault at 122 ip 00007f8c747b4353 sp 00007f8c5e7af330 error 6 in chromium-browser[7f8c7395e000+3e95000] Feb 11 19:39:30 blodnatt kernel: : [ 405.599777] chromium-browse[3725]: segfault at 122 ip 00007f8c747b4353 sp 00007f8c5e7af330 error 6 in chromium-browser[7f8c7395e000+3e95000] Feb 11 19:39:30 blodnatt kernel: : [ 405.622623] chromium-browse[3732]: segfault at 122 ip 00007f8c747b4353 sp 00007f8c5e7af330 error 6 in chromium-browser[7f8c7395e000+3e95000] Feb 11 19:39:30 blodnatt kernel: : [ 405.637877] chromium-browse[3736]: segfault at 122 ip 00007f8c747b4353 sp 00007f8c5e7af330 error 6 in chromium-browser[7f8c7395e000+3e95000] Feb 11 19:39:30 blodnatt kernel: : [ 405.693884] chromium-browse[3742]: segfault at 122 ip 00007f8c747b4353 sp 00007f8c5e7af330 error 6 in chromium-browser[7f8c7395e000+3e95000] Feb 11 19:39:30 blodnatt kernel: : [ 405.726017] chromium-browse[3746]: segfault at 122 ip 00007f8c747b4353 sp 00007f8c5e7af330 error 6 in chromium-browser[7f8c7395e000+3e95000] Feb 11 19:39:30 blodnatt kernel: : [ 405.754289] chromium-browse[3753]: segfault at 122 ip 00007f8c747b4353 sp 00007f8c5e7af330 error 6 in chromium-browser[7f8c7395e000+3e95000] Feb 11 19:39:30 blodnatt kernel: : [ 405.865100] chromium-browse[3757]: segfault at 122 ip 00007f8c747b4353 sp 00007f8c5e7af330 error 6 in chromium-browser[7f8c7395e000+3e95000] Feb 11 19:40:31 blodnatt kernel: : [ 466.213160] chromium-browse[4938]: segfault at 122 ip 00007fc083ddb353 sp 00007fc06ddd6330 error 6 in chromium-browser[7fc082f85000+3e95000] Feb 11 19:40:31 blodnatt kernel: : [ 466.220722] chromium-browse[4941]: segfault at 122 ip 00007fc083ddb353 sp 00007fc06ddd6330 error 6 in chromium-browser[7fc082f85000+3e95000] Feb 11 19:40:31 blodnatt kernel: : [ 466.249485] chromium-browse[4949]: segfault at 122 ip 00007fc083ddb353 sp 00007fc06ddd6330 error 6 in chromium-browser[7fc082f85000+3e95000] Feb 11 19:40:31 blodnatt kernel: : [ 466.268072] chromium-browse[4954]: segfault at 122 ip 00007fc083ddb353 sp 00007fc06ddd6330 error 6 in chromium-browser[7fc082f85000+3e95000] Feb 11 19:40:31 blodnatt kernel: : [ 466.278388] chromium-browse[4959]: segfault at 122 ip 00007fc083ddb353 sp 00007fc06ddd6330 error 6 in chromium-browser[7fc082f85000+3e95000] Feb 11 19:40:31 blodnatt kernel: : [ 466.317336] chromium-browse[4964]: segfault at 122 ip 00007fc083ddb353 sp 00007fc06ddd6330 error 6 in chromium-browser[7fc082f85000+3e95000] Feb 11 19:40:31 blodnatt kernel: : [ 466.373686] chromium-browse[4969]: segfault at 122 ip 00007fc083ddb353 sp 00007fc06ddd6330 error 6 in chromium-browser[7fc082f85000+3e95000] Feb 11 19:40:31 blodnatt kernel: : [ 466.395218] chromium-browse[4974]: segfault at 122 ip 00007fc083ddb353 sp 00007fc06ddd6330 error 6 in chromium-browser[7fc082f85000+3e95000] Feb 11 19:40:31 blodnatt kernel: : [ 466.530506] chromium-browse[4978]: segfault at 122 ip 00007fc083ddb353 sp 00007fc06ddd6330 error 6 in chromium-browser[7fc082f85000+3e95000] $ grep -r __NR_.*290 /usr/include/asm /usr/include/asm/unistd_32.h:#define __NR_ioprio_get 290 /usr/include/asm/unistd_64.h:#define __NR_eventfd2 290 /usr/include/asm/unistd_x32.h:#define __NR_eventfd2 (__X32_SYSCALL_BIT + 290) so seems different problem, you could try patch similarily by allowing __NR_eventfd2 ? ps: you can add --disable-seccomp-filter-sandbox to /etc/chromium-browser/default as CHROMIUM_FLAGS env var or "Chrome Flags" inside profile (as text file) to make the option more permanent. also $CHROMIUM_USER_FLAGS works as well (put it to your ~/.*profile) if you don't create the "Chrome Flags" file. -- glen From glen at pld-linux.org Tue Feb 12 11:32:57 2013 From: glen at pld-linux.org (=?UTF-8?B?RWxhbiBSdXVzYW3DpGU=?=) Date: Tue, 12 Feb 2013 12:32:57 +0200 Subject: [TH - 64] Chromium chromoli po upgrade In-Reply-To: <511A181F.90108@pld-linux.org> References: <50B7DC6B.1020005@o2.pl> <50B8730A.2000600@sojka.co> <201211300954.20652@laptok.ed.pl> <3330068.pSP6KcgNKF@inhell> <511A181F.90108@pld-linux.org> Message-ID: <511A1A59.30704@pld-linux.org> On 12.02.2013 12:23, Elan Ruusam?e wrote: > as much i understood reading the bugreport then "segfault at NUMBER", > means syscall NUMBER in HEX, the reports you referred had 0x19, but > our (yours and mine) are 0x122 hex (290 dec) which is different syscall: > > Feb 11 19:38:59 blodnatt kernel: : [ 375.154516] > chromium-browse[3544]: segfault at 122 ip 00007f3f9c5ea353 sp > 00007f3f865e5330 error 6 in chromium-browser[7f3f9b794000+3e95000] > Feb 11 19:39:00 blodnatt kernel: : [ 375.292081] > chromium-browse[3551]: segfault at 122 ip 00007f3f9c5ea353 sp > 00007f3f865e5330 error 6 in chromium-browser[7f3f9b794000+3e95000] > Feb 11 19:39:00 blodnatt kernel: : [ 375.857206] > chromium-browse[3563]: segfault at 122 ip 00007f3f9c5ea353 sp > 00007f3f865e5330 error 6 in chromium-browser[7f3f9b794000+3e95000] > ... > Feb 11 19:40:31 blodnatt kernel: : [ 466.530506] > chromium-browse[4978]: segfault at 122 ip 00007fc083ddb353 sp > 00007fc06ddd6330 error 6 in chromium-browser[7fc082f85000+3e95000] > > > $ grep -r __NR_.*290 /usr/include/asm > /usr/include/asm/unistd_32.h:#define __NR_ioprio_get 290 > /usr/include/asm/unistd_64.h:#define __NR_eventfd2 290 > /usr/include/asm/unistd_x32.h:#define __NR_eventfd2 (__X32_SYSCALL_BIT > + 290) found only 1 bug matching same segfault at pattern: https://code.google.com/p/chromium/issues/detail?id=169421 -- glen From arekm at maven.pl Tue Feb 12 13:11:40 2013 From: arekm at maven.pl (Arkadiusz =?utf-8?q?Mi=C5=9Bkiewicz?=) Date: Tue, 12 Feb 2013 13:11:40 +0100 Subject: [TH - 64] Chromium chromoli po upgrade In-Reply-To: <3330068.pSP6KcgNKF@inhell> References: <50B7DC6B.1020005@o2.pl> <201211300954.20652@laptok.ed.pl> <3330068.pSP6KcgNKF@inhell> Message-ID: <201302121311.41088.arekm@maven.pl> On Monday 11 of February 2013, Lukasz Glebicki wrote: > On Friday 30 of November 2012 09:54:20 ?ukasz Ma?ko wrote: > > Dnia pi?tek, 30 listopada 2012, Grzegorz S?jka napisa?: > > > U mnie chromium-browser-23.0.1271.64-3.x86_64 te? si? wywraca. Na dw?ch > > > r??nych maszynach x86_64 te same objawy. Pojawia si? okno ale zamiast > > > strony startowej na ?rodku jest smutna mordka i komentarz, ?e co? > > > posz?o nie tak. Dmesg wywala: > > > > > > [ 282.276966] chromium-browse[2097]: segfault at 122 ip > > > 00007fafd200d713 sp 00007fafb7372370 error 6 in > > > chromium-browser[7fafd11d3000+3d17000] > > > [ 294.557690] chromium-browse[2119]: segfault at 122 ip > > > 00007fafd200d713 sp 00007fafb7372370 error 6 in > > > chromium-browser[7fafd11d3000+3d17000] > > > > Czy?by pierwszy raz od dawna, ?e i686 jest OK a na x86_64 nie? Could you try with libevent 2.0.21 on x86_64? -- Arkadiusz Mi?kiewicz, arekm / maven.pl From glen at pld-linux.org Tue Feb 12 14:17:03 2013 From: glen at pld-linux.org (=?UTF-8?B?RWxhbiBSdXVzYW3DpGU=?=) Date: Tue, 12 Feb 2013 15:17:03 +0200 Subject: [TH - 64] Chromium chromoli po upgrade In-Reply-To: <201302121311.41088.arekm@maven.pl> References: <50B7DC6B.1020005@o2.pl> <201211300954.20652@laptok.ed.pl> <3330068.pSP6KcgNKF@inhell> <201302121311.41088.arekm@maven.pl> Message-ID: <511A40CF.7050302@pld-linux.org> On 12.02.2013 14:11, Arkadiusz Mi?kiewicz wrote: > Could you try with libevent 2.0.21 on x86_64? confirmed by me and baggins [1], try chromium-browser-24.0.1312.69-2 from th-test [2] [1] http://git.pld-linux.org/gitweb.cgi?p=packages/chromium-browser.git;a=commitdiff;h=56403697bec52d108393df2e185b7555c869351e [2] http://src.th.pld-linux.org/queue.html#95427 -- glen From glen at pld-linux.org Tue Feb 12 14:19:29 2013 From: glen at pld-linux.org (=?ISO-8859-1?Q?Elan_Ruusam=E4e?=) Date: Tue, 12 Feb 2013 15:19:29 +0200 Subject: empathy abort Message-ID: <511A4161.5080407@pld-linux.org> i see that chromium crash was resolved quite quickly, perhaps any ideas why empathy is failing? i do not find any package update being relevant from my system, as i don't know when it actually broke (it's long running app here) $ empathy & (empathy:5937): Gdk-ERROR **: The program 'empathy' received an X Window System error. This probably reflects a bug in the program. The error was 'BadValue (integer parameter out of range for operation)'. (Details: serial 174 error_code 2 request_code 131 minor_code 47) (Note to programmers: normally, X errors are reported asynchronously; that is, you will receive the error a while after causing it. To debug your program, run it with the GDK_SYNCHRONIZE environment variable to change this behavior. You can then get a meaningful backtrace from your debugger if you break on the gdk_x_error() function.) [1]+ Trace/breakpoint trap empathy -- glen From lukaszgl at post.pl Tue Feb 12 16:06:56 2013 From: lukaszgl at post.pl (Lukasz Glebicki) Date: Tue, 12 Feb 2013 16:06:56 +0100 Subject: [TH - 64] Chromium chromoli po upgrade In-Reply-To: <511A40CF.7050302@pld-linux.org> References: <50B7DC6B.1020005@o2.pl> <201302121311.41088.arekm@maven.pl> <511A40CF.7050302@pld-linux.org> Message-ID: <2361371.46uT82IULc@inhell> On Tuesday 12 of February 2013 15:17:03 Elan Ruusam?e wrote: > On 12.02.2013 14:11, Arkadiusz Mi?kiewicz wrote: > > Could you try with libevent 2.0.21 on x86_64? > > confirmed by me and baggins [1], try chromium-browser-24.0.1312.69-2 > from th-test [2] > > [1] > http://git.pld-linux.org/gitweb.cgi?p=packages/chromium-browser.git;a=commit > diff;h=56403697bec52d108393df2e185b7555c869351e [2] > http://src.th.pld-linux.org/queue.html#95427 Works! Great thanks. Kind Regards, -- ?ukasz G??bicki mail/rot13:yhxnfmty at cbfg.cy PLD/Linux Team gg:246267 Linux Registered User #318551 blekot:{irc,skype} From qboosh at pld-linux.org Tue Feb 12 16:13:55 2013 From: qboosh at pld-linux.org (Jakub Bogusz) Date: Tue, 12 Feb 2013 16:13:55 +0100 Subject: [packages/xorg-app-xinit] R: ConsoleKit-x11 In-Reply-To: <67064c06ddc589cdc4b98fe0b0bb15d0fda5ee40_refs_heads_master@pld-linux.org> References: <67064c06ddc589cdc4b98fe0b0bb15d0fda5ee40_refs_heads_master@pld-linux.org> Message-ID: <20130212151355.GA20277@mail> On Mon, Feb 11, 2013 at 10:33:25PM +0100, glen wrote: > commit 67064c06ddc589cdc4b98fe0b0bb15d0fda5ee40 > Author: Elan Ruusam?e > Date: Mon Feb 11 23:33:22 2013 +0200 > > R: ConsoleKit-x11 > > xorg-app-xinit.spec | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) I'd suggest Suggests... startx works fine without it. Am I missing something? -- Jakub Bogusz http://qboosh.pl/ From megabajt at pld-linux.org Tue Feb 12 16:25:59 2013 From: megabajt at pld-linux.org (Marcin Banasiak) Date: Tue, 12 Feb 2013 16:25:59 +0100 Subject: empathy abort In-Reply-To: <511A4161.5080407@pld-linux.org> References: <511A4161.5080407@pld-linux.org> Message-ID: 2013/2/12 Elan Ruusam?e : > i see that chromium crash was resolved quite quickly, perhaps any ideas why > empathy is failing? > i do not find any package update being relevant from my system, as i don't > know when it actually broke (it's long running app here) > > $ empathy & > (empathy:5937): Gdk-ERROR **: The program 'empathy' received an X Window > System error. > This probably reflects a bug in the program. > The error was 'BadValue (integer parameter out of range for operation)'. > (Details: serial 174 error_code 2 request_code 131 minor_code 47) > (Note to programmers: normally, X errors are reported asynchronously; > that is, you will receive the error a while after causing it. > To debug your program, run it with the GDK_SYNCHRONIZE environment > variable to change this behavior. You can then get a meaningful > backtrace from your debugger if you break on the gdk_x_error() function.) clutter-1.12.2-2 from th-test should help. -- Marcin Banasiak From glen at pld-linux.org Tue Feb 12 16:41:35 2013 From: glen at pld-linux.org (=?ISO-8859-1?Q?Elan_Ruusam=E4e?=) Date: Tue, 12 Feb 2013 17:41:35 +0200 Subject: [packages/xorg-app-xinit] R: ConsoleKit-x11 In-Reply-To: <20130212151355.GA20277@mail> References: <67064c06ddc589cdc4b98fe0b0bb15d0fda5ee40_refs_heads_master@pld-linux.org> <20130212151355.GA20277@mail> Message-ID: <511A62AF.4030302@pld-linux.org> On 12.02.2013 17:13, Jakub Bogusz wrote: > On Mon, Feb 11, 2013 at 10:33:25PM +0100, glen wrote: >> commit 67064c06ddc589cdc4b98fe0b0bb15d0fda5ee40 >> Author: Elan Ruusam?e >> Date: Mon Feb 11 23:33:22 2013 +0200 >> >> R: ConsoleKit-x11 >> >> xorg-app-xinit.spec | 3 ++- >> 1 file changed, 2 insertions(+), 1 deletion(-) > I'd suggest Suggests... startx works fine without it. > Am I missing something? yeah, seems fine, just it's somewhat buggy twm/xorg (under vbox) that lead me to that understanding. it was all screen was black, even mouse with X cursor did not appear until you clicked on root window where twm menu popped up, and after that mouse cursor changed to the "default" i'm used to (when no customization is made). so, true, can be turned to suggests. -- glen From glen at pld-linux.org Tue Feb 12 16:57:10 2013 From: glen at pld-linux.org (=?UTF-8?B?RWxhbiBSdXVzYW3DpGU=?=) Date: Tue, 12 Feb 2013 17:57:10 +0200 Subject: empathy certs (Re: empathy abort) In-Reply-To: References: <511A4161.5080407@pld-linux.org> Message-ID: <511A6656.8050707@pld-linux.org> On 12.02.2013 17:25, Marcin Banasiak wrote: > 2013/2/12 Elan Ruusam?e : >> i see that chromium crash was resolved quite quickly, perhaps any ideas why >> empathy is failing? >> ... >> >> clutter-1.12.2-2 from th-test should help. >> can you also solve problem that empathy fails to save any cert even i check "do not ask me again" https://dl.dropbox.com/u/8879577/ss/2013-02-12_17.54.21.png -- glen From glen at pld-linux.org Tue Feb 12 18:19:09 2013 From: glen at pld-linux.org (=?UTF-8?B?RWxhbiBSdXVzYW3DpGU=?=) Date: Tue, 12 Feb 2013 19:19:09 +0200 Subject: empathy abort In-Reply-To: References: <511A4161.5080407@pld-linux.org> Message-ID: <511A798D.10403@pld-linux.org> On 12.02.2013 17:25, Marcin Banasiak wrote: >> backtrace from your debugger if you break on the gdk_x_error() function.) > clutter-1.12.2-2 from th-test should help. yes. helped -- glen From megabajt at pld-linux.org Tue Feb 12 18:52:12 2013 From: megabajt at pld-linux.org (Marcin Banasiak) Date: Tue, 12 Feb 2013 18:52:12 +0100 Subject: empathy certs (Re: empathy abort) In-Reply-To: <511A6656.8050707@pld-linux.org> References: <511A4161.5080407@pld-linux.org> <511A6656.8050707@pld-linux.org> Message-ID: 2013/2/12 Elan Ruusam?e: > can you also solve problem that empathy fails to save any cert even i check > "do not ask me again" > > https://dl.dropbox.com/u/8879577/ss/2013-02-12_17.54.21.png It works as expected here. I don't know whether you are using GNOME, but it looks like missing pkcs11 component in gnome-keyring-daemon. -- Marcin Banasiak From glen at pld-linux.org Tue Feb 12 23:24:27 2013 From: glen at pld-linux.org (=?UTF-8?Q?Elan_Ruusam=C3=A4e?=) Date: Wed, 13 Feb 2013 00:24:27 +0200 Subject: empathy certs (Re: empathy abort) In-Reply-To: References: <511A4161.5080407@pld-linux.org> <511A6656.8050707@pld-linux.org> Message-ID: <39392e508118380bafe24509683b3f6b@delfi.ee> On 2013-02-12 19:52, Marcin Banasiak wrote: > 2013/2/12 Elan Ruusam?e: >> can you also solve problem that empathy fails to save any cert even >> i check >> "do not ask me again" >> >> https://dl.dropbox.com/u/8879577/ss/2013-02-12_17.54.21.png > > It works as expected here. I don't know whether you are using GNOME, > but it looks like missing pkcs11 component in gnome-keyring-daemon. well. that dialog is given me repeatedly, even i check "remember" checkbox. and not just at startup, time to time when app runs as well. rather annoying. i'll check the keyring components tomorrow. can't figure out from ps listing is it enabled or not. glen 4059 0.0 0.1 372004 6336 ? SLl Feb12 0:00 /usr/bin/gnome-keyring-daemon --daemonize --login the problem was present in GNOME3 too, currently the desktop is MATE -- glen From glen at pld-linux.org Wed Feb 13 16:32:49 2013 From: glen at pld-linux.org (=?ISO-8859-1?Q?Elan_Ruusam=E4e?=) Date: Wed, 13 Feb 2013 17:32:49 +0200 Subject: [packages/chromium-browser] requires _XGetRequest In-Reply-To: <2cbfc1a4ea176c3c6430f45613d3fb707a447294_refs_heads_master@pld-linux.org> References: <2cbfc1a4ea176c3c6430f45613d3fb707a447294_refs_heads_master@pld-linux.org> Message-ID: <511BB221.2030700@pld-linux.org> On 13.02.2013 17:30, gotar wrote: > commit 2cbfc1a4ea176c3c6430f45613d3fb707a447294 > Author: Tomasz Pala > Date: Wed Feb 13 16:28:04 2013 +0100 > > requires _XGetRequest > > chromium-browser.spec | 1 + > 1 file changed, 1 insertion(+) > --- > diff --git a/chromium-browser.spec b/chromium-browser.spec > index 267ba27..fc1cc2c 100644 > --- a/chromium-browser.spec > +++ b/chromium-browser.spec > @@ -204,6 +204,7 @@ Requires: libevent >= 2.0.21 > Requires: lsb-release > Requires: shared-mime-info > Requires: xdg-utils >= 1.0.2-4 > +Requires: xorg-lib-libX11 >= 1.4.99.1 > Provides: wwwbrowser > Obsoletes: chromium-browser-bookmark_manager < 5.0.388.0 > Obsoletes: chromium-browser-inspector < 15.0.863.0 > shouldn't appropriate versioned BR be filled as well? -- glen From qboosh at pld-linux.org Wed Feb 13 17:07:05 2013 From: qboosh at pld-linux.org (Jakub Bogusz) Date: Wed, 13 Feb 2013 17:07:05 +0100 Subject: [packages/chromium-browser] requires _XGetRequest In-Reply-To: <511BB221.2030700@pld-linux.org> References: <2cbfc1a4ea176c3c6430f45613d3fb707a447294_refs_heads_master@pld-linux.org> <511BB221.2030700@pld-linux.org> Message-ID: <20130213160705.GA23369@mail> On Wed, Feb 13, 2013 at 05:32:49PM +0200, Elan Ruusam?e wrote: > On 13.02.2013 17:30, gotar wrote: > >commit 2cbfc1a4ea176c3c6430f45613d3fb707a447294 > >Author: Tomasz Pala > >Date: Wed Feb 13 16:28:04 2013 +0100 > > > > requires _XGetRequest > > > > chromium-browser.spec | 1 + > > 1 file changed, 1 insertion(+) > >--- > >diff --git a/chromium-browser.spec b/chromium-browser.spec > >index 267ba27..fc1cc2c 100644 > >--- a/chromium-browser.spec > >+++ b/chromium-browser.spec > >@@ -204,6 +204,7 @@ Requires: libevent >= 2.0.21 > > Requires: lsb-release > > Requires: shared-mime-info > > Requires: xdg-utils >= 1.0.2-4 > >+Requires: xorg-lib-libX11 >= 1.4.99.1 > > Provides: wwwbrowser > > Obsoletes: chromium-browser-bookmark_manager < 5.0.388.0 > > Obsoletes: chromium-browser-inspector < 15.0.863.0 > > > > shouldn't appropriate versioned BR be filled as well? Yes, this R is useless if package is built with older libX11. Issue is more global - every application/library that uses X11's GetReq and similar macros starts to require libX11 >= 1.4.99 when it's built with libX11 >= 1.4.99. -- Jakub Bogusz http://qboosh.pl/ From glen at pld-linux.org Wed Feb 13 17:23:10 2013 From: glen at pld-linux.org (=?ISO-8859-1?Q?Elan_Ruusam=E4e?=) Date: Wed, 13 Feb 2013 18:23:10 +0200 Subject: [packages/chromium-browser] requires _XGetRequest In-Reply-To: <20130213160705.GA23369@mail> References: <2cbfc1a4ea176c3c6430f45613d3fb707a447294_refs_heads_master@pld-linux.org> <511BB221.2030700@pld-linux.org> <20130213160705.GA23369@mail> Message-ID: <511BBDEE.10302@pld-linux.org> On 13.02.2013 18:07, Jakub Bogusz wrote: > Yes, this R is useless if package is built with older libX11. > > Issue is more global - every application/library that uses X11's > GetReq and similar macros starts to require libX11 >= 1.4.99 > when it's built with libX11 >= 1.4.99. > and it's more global than this: this happens to be the case with other gnomeish libs as well: glib, gtk+2.... it has been addressed earlier with upstream (by patrys), to make soname versions, but upstream declined that plan for gtk+2/gtk+3 sorry no links to mailinglist, or samples or other libs, but i'm sure the topic itself is not new. could this be addressed by rpm side? %requires_eq is not the solution i'm seeking, as that would cause pointless rebuilds and upgrades if nothing has changed between versions. -- glen From qboosh at pld-linux.org Wed Feb 13 18:17:18 2013 From: qboosh at pld-linux.org (Jakub Bogusz) Date: Wed, 13 Feb 2013 18:17:18 +0100 Subject: [packages/chromium-browser] requires _XGetRequest In-Reply-To: <511BBDEE.10302@pld-linux.org> References: <2cbfc1a4ea176c3c6430f45613d3fb707a447294_refs_heads_master@pld-linux.org> <511BB221.2030700@pld-linux.org> <20130213160705.GA23369@mail> <511BBDEE.10302@pld-linux.org> Message-ID: <20130213171717.GC23369@mail> On Wed, Feb 13, 2013 at 06:23:10PM +0200, Elan Ruusam?e wrote: > On 13.02.2013 18:07, Jakub Bogusz wrote: > >Yes, this R is useless if package is built with older libX11. > > > >Issue is more global - every application/library that uses X11's > >GetReq and similar macros starts to require libX11 >= 1.4.99 > >when it's built with libX11 >= 1.4.99. > > > and it's more global than this: this happens to be the case with other > gnomeish libs as well: glib, gtk+2.... > > it has been addressed earlier with upstream (by patrys), to make soname > versions, but upstream declined that plan for gtk+2/gtk+3 soname changes should happen when binary interfaces are removed or incompatible. Bumping on added interface would cause too many unnecessary rebuilds. Better solution would be versioned symbols (like in glibc, nss or few other libs), already handled by rpm. > sorry no links to mailinglist, or samples or other libs, but i'm sure > the topic itself is not new. > > could this be addressed by rpm side? > %requires_eq is not the solution i'm seeking, as that would cause > pointless rebuilds and upgrades if nothing has changed between versions. When versioned symbols are not used, %requires_ge_to could be some solution (also not perfect). Maintaining symbol lists for rpm automation would require probably too much effort. And finally generating per-symbol dependencies would comsume too much resources. -- Jakub Bogusz http://qboosh.pl/ From gotar at polanet.pl Wed Feb 13 18:57:44 2013 From: gotar at polanet.pl (Tomasz Pala) Date: Wed, 13 Feb 2013 18:57:44 +0100 Subject: [packages/chromium-browser] requires _XGetRequest In-Reply-To: <20130213160705.GA23369@mail> References: <2cbfc1a4ea176c3c6430f45613d3fb707a447294_refs_heads_master@pld-linux.org> <511BB221.2030700@pld-linux.org> <20130213160705.GA23369@mail> Message-ID: <20130213175743.GA22743@polanet.pl> On Wed, Feb 13, 2013 at 17:07:05 +0100, Jakub Bogusz wrote: > On Wed, Feb 13, 2013 at 05:32:49PM +0200, Elan Ruusam?e wrote: >> > >> > requires _XGetRequest >> > >> >+Requires: xorg-lib-libX11 >= 1.4.99.1 >> >> shouldn't appropriate versioned BR be filled as well? No, as apps detect if this symbol is available at build time. However - since we do have libX11-devel with this symbol, there must be something to trigger update. The same applies to libXrandr. > Yes, this R is useless if package is built with older libX11. Yep. > Issue is more global - every application/library that uses X11's > GetReq and similar macros starts to require libX11 >= 1.4.99 > when it's built with libX11 >= 1.4.99. These two were the only ones I've found during last month. I keep old libraries on purpose to hit such cases. -- Tomasz Pala From gotar at polanet.pl Wed Feb 13 19:13:22 2013 From: gotar at polanet.pl (Tomasz Pala) Date: Wed, 13 Feb 2013 19:13:22 +0100 Subject: [packages/chromium-browser] requires _XGetRequest In-Reply-To: <511BBDEE.10302@pld-linux.org> References: <2cbfc1a4ea176c3c6430f45613d3fb707a447294_refs_heads_master@pld-linux.org> <511BB221.2030700@pld-linux.org> <20130213160705.GA23369@mail> <511BBDEE.10302@pld-linux.org> Message-ID: <20130213181322.GB22743@polanet.pl> On Wed, Feb 13, 2013 at 18:23:10 +0200, Elan Ruusam?e wrote: >> Issue is more global - every application/library that uses X11's >> GetReq and similar macros starts to require libX11 >= 1.4.99 >> when it's built with libX11 >= 1.4.99. >> > and it's more global than this: this happens to be the case with other > gnomeish libs as well: glib, gtk+2.... Well, this is even more global /in general/;) It happens in various libs that are enhanced, I recall doing a few commits like this in the past. Ideally, these R might be removed when sover is bumped, making particular symbol irrevelant as lib would be upgraded anyway. There is no efficient mechanism to track such dependencies (->dependency hell) unless one does 'upgrade *' and evades this problem (or something else just triggers appropriate update). > could this be addressed by rpm side? > %requires_eq is not the solution i'm seeking, as that would cause > pointless rebuilds and upgrades if nothing has changed between versions. Only by creating (manually) a database with such 'enhancements'. Every package that gets rebuild in environment having listed libraries should automatically get specified R. But I think it's not worth it - any case we spot (they are really rare) have big chances to be already late and some packages will alredy be rebuilded. -- Tomasz Pala From gotar at polanet.pl Wed Feb 13 20:12:19 2013 From: gotar at polanet.pl (Tomasz Pala) Date: Wed, 13 Feb 2013 20:12:19 +0100 Subject: [packages/chromium-browser] requires _XGetRequest In-Reply-To: <20130213181322.GB22743@polanet.pl> References: <2cbfc1a4ea176c3c6430f45613d3fb707a447294_refs_heads_master@pld-linux.org> <511BB221.2030700@pld-linux.org> <20130213160705.GA23369@mail> <511BBDEE.10302@pld-linux.org> <20130213181322.GB22743@polanet.pl> Message-ID: <20130213191219.GA26747@polanet.pl> On Wed, Feb 13, 2013 at 19:13:22 +0100, Tomasz Pala wrote: > Well, this is even more global /in general/;) It happens in various libs that are > enhanced, I recall doing a few commits like this in the past. I've just found another example in my private master (and just pushed it): http://git.pld-linux.org/?p=packages/glibc.git;a=commitdiff;h=0c48ee453c949997e4c12506cbd80d6f04565146 It is similar in a way, that it's not automatically pulled by any existing dependencies and might pop on random user. It differs as it's not symbol-dependent and there's no R but C. This can't be automated... -- Tomasz Pala From glen at pld-linux.org Thu Feb 14 09:58:06 2013 From: glen at pld-linux.org (=?ISO-8859-1?Q?Elan_Ruusam=E4e?=) Date: Thu, 14 Feb 2013 10:58:06 +0200 Subject: [packages/chromium-browser] requires _XGetRequest In-Reply-To: <20130213171717.GC23369@mail> References: <2cbfc1a4ea176c3c6430f45613d3fb707a447294_refs_heads_master@pld-linux.org> <511BB221.2030700@pld-linux.org> <20130213160705.GA23369@mail> <511BBDEE.10302@pld-linux.org> <20130213171717.GC23369@mail> Message-ID: <511CA71E.1060407@pld-linux.org> On 13.02.2013 19:17, Jakub Bogusz wrote: >> and it's more global than this: this happens to be the case with other >> >gnomeish libs as well: glib, gtk+2.... >> > >> >it has been addressed earlier with upstream (by patrys), to make soname >> >versions, but upstream declined that plan for gtk+2/gtk+3 > soname changes should happen when binary interfaces are removed or > incompatible. > Bumping on added interface would cause too many unnecessary rebuilds. > > Better solution would be versioned symbols (like in glibc, nss or few > other libs), already handled by rpm. > yes, i meant "versioned symbols" -- glen From glen at pld-linux.org Thu Feb 14 10:04:10 2013 From: glen at pld-linux.org (=?ISO-8859-1?Q?Elan_Ruusam=E4e?=) Date: Thu, 14 Feb 2013 11:04:10 +0200 Subject: [packages/chromium-browser] requires _XGetRequest In-Reply-To: <20130213171717.GC23369@mail> References: <2cbfc1a4ea176c3c6430f45613d3fb707a447294_refs_heads_master@pld-linux.org> <511BB221.2030700@pld-linux.org> <20130213160705.GA23369@mail> <511BBDEE.10302@pld-linux.org> <20130213171717.GC23369@mail> Message-ID: <511CA88A.5020601@pld-linux.org> On 13.02.2013 19:17, Jakub Bogusz wrote: > Maintaining symbol lists for rpm automation would require probably too > much effort. but if it's just pairs of such detections, so if you find incompatibility, you register it once, and all packages being built with affected library exceeding specific version at build time, gets version >= dependency at runtime a list: xorg-lib-libX11 >= 1.3.99.1 xorg-lib-libX11 >= 1.4.99.1 when a packages gets produced, which depends on xorg-lib-libX11 (via soname dep) it will check, whether xorg-lib-libX11 is in the list tries to match if it falls between any of the versions and in case of 1.5 it would fill extra dep (or update existing one) with xorg-lib-libX11 >= 1.4.99.1 benefit of this approach is that once incompatibility is found, any other rebuild will get the fix automatically, without need to update .spec files with a versioned dependency. just an idea, i have not fully thought it trough. -- glen From glen at delfi.ee Thu Feb 14 15:33:22 2013 From: glen at delfi.ee (=?ISO-8859-1?Q?Elan_Ruusam=E4e?=) Date: Thu, 14 Feb 2013 16:33:22 +0200 Subject: gtkspell-3.0.pc Message-ID: <511CF5B2.2010100@delfi.ee> hi how gtkspell 3.x should be packaged? http://gtkspell.sourceforge.net/ says: Downloads The latest version is 3.0.1, released on 2013-02-07 (README, ChangeLog). This release supports both GTK+ 2 and GTK+ 3 and is not API-compatible with the 2.x release. 3.0.1 Source Tarball The latest legacy (GTK+ 2 only) 2.x version is 2.0.16, released on 2009-10-22. 2.0.16 Source Tarball should current gtkspell.spec kept for 2.x? upgraded to 3.x? 2.x packaged to gtkspell2, 3.x packaged to gtkspell3 ... ? -- glen From megabajt at pld-linux.org Thu Feb 14 15:54:56 2013 From: megabajt at pld-linux.org (Marcin Banasiak) Date: Thu, 14 Feb 2013 15:54:56 +0100 Subject: gtkspell-3.0.pc In-Reply-To: <511CF5B2.2010100@delfi.ee> References: <511CF5B2.2010100@delfi.ee> Message-ID: 2013/2/14 Elan Ruusam?e: > how gtkspell 3.x should be packaged? I think that we should upgrade gtkspell.spec to 3.x and create gtkspell2.spec for 2.x. Sooner or later packages that depend on 2.x will be ported to the new API and then we can simply remove gtkspell2. -- Marcin Banasiak From glen at pld-linux.org Thu Feb 14 16:17:20 2013 From: glen at pld-linux.org (=?UTF-8?B?RWxhbiBSdXVzYW3DpGU=?=) Date: Thu, 14 Feb 2013 17:17:20 +0200 Subject: gtkspell-3.0.pc In-Reply-To: References: <511CF5B2.2010100@delfi.ee> Message-ID: <511D0000.3040306@pld-linux.org> On 14.02.2013 16:54, Marcin Banasiak wrote: > 2013/2/14 Elan Ruusam?e: >> how gtkspell 3.x should be packaged? > I think that we should upgrade gtkspell.spec to 3.x and create > gtkspell2.spec for 2.x. Sooner or later packages that depend on 2.x > will be ported to the new API and then we can simply remove gtkspell2. > seems upstream tarball name is gtkspell3, library names gtkspell3-3.pc etc, seems better to clone current to gtkspell3 ... so, either way is fine to me, somebody just has to say which way :) also, when somebody creates gtkspell2, does he know how to drop commits that are with 3.x, i.e "git reset --hard SHA1", or he will just clone whatever version is there and apply reverse patch? so, i'm afraid people behave like option b) therefore i'd clone the package to gtkspell3 now. -- glen From qboosh at pld-linux.org Thu Feb 14 16:33:46 2013 From: qboosh at pld-linux.org (Jakub Bogusz) Date: Thu, 14 Feb 2013 16:33:46 +0100 Subject: gtkspell-3.0.pc In-Reply-To: <511D0000.3040306@pld-linux.org> References: <511CF5B2.2010100@delfi.ee> <511D0000.3040306@pld-linux.org> Message-ID: <20130214153346.GA27105@mail> On Thu, Feb 14, 2013 at 05:17:20PM +0200, Elan Ruusam?e wrote: > On 14.02.2013 16:54, Marcin Banasiak wrote: > >2013/2/14 Elan Ruusam?e: > >>how gtkspell 3.x should be packaged? > >I think that we should upgrade gtkspell.spec to 3.x and create > >gtkspell2.spec for 2.x. Sooner or later packages that depend on 2.x > >will be ported to the new API and then we can simply remove gtkspell2. > > > seems upstream tarball name is gtkspell3, library names gtkspell3-3.pc > etc, seems better to clone current to gtkspell3 ... > > so, either way is fine to me, somebody just has to say which way :) In such case (gtkspell3 everywhere) I'd use gtkspell3.spec. -- Jakub Bogusz http://qboosh.pl/ From lukaszgl at post.pl Sat Feb 16 19:15:56 2013 From: lukaszgl at post.pl (Lukasz Glebicki) Date: Sat, 16 Feb 2013 19:15:56 +0100 Subject: amarok Message-ID: <25208390.novHtiWRFd@inhell> amarok-2.6.0-2is not ready to go to main in that state and there is no possibility to come back to 2.6.0-1, due to the libcdio-paranoia library, which cannot be downgraded. Amarok crashes and log says: [WARNING] [PluginManager] "Failed to get factory 'amarok_collection- mysqlservercollection' from KPluginLoader: The plugin 'amarok_collection- mysqlservercollection' uses an incompatible KDE library (4.9.5)." It works with kde 4.10.0 from test but kde is not working well after upgrade. -- ?ukasz G??bicki mail/rot13:yhxnfmty at cbfg.cy PLD/Linux Team gg:246267 Linux Registered User #318551 blekot:{irc,skype} From ed at yen.ipipan.waw.pl Sat Feb 16 19:25:03 2013 From: ed at yen.ipipan.waw.pl (=?utf-8?B?xYF1a2FzeiBNYcWba28=?=) Date: Sat, 16 Feb 2013 19:25:03 +0100 Subject: amarok In-Reply-To: <25208390.novHtiWRFd@inhell> References: <25208390.novHtiWRFd@inhell> Message-ID: <45371500.mD3d3vKdLz@laptok> Dnia sobota, 16 lutego 2013 19:15:56 Lukasz Glebicki pisze: [...] > It works with kde 4.10.0 from test but kde is not working well after > upgrade. What is wrong with your KDE after upgrade? Any details? -- ?ukasz Ma?ko _o) Lukasz.Masko(at)ipipan.waw.pl /\\ Registered Linux User #61028 _\_V Ubuntu: staroafryka?skie s?owo oznaczaj?ce "Nie umiem zainstalowa? Debiana" From lukaszgl at post.pl Sun Feb 17 12:21:17 2013 From: lukaszgl at post.pl (Lukasz Glebicki) Date: Sun, 17 Feb 2013 12:21:17 +0100 Subject: amarok In-Reply-To: <45371500.mD3d3vKdLz@laptok> References: <25208390.novHtiWRFd@inhell> <45371500.mD3d3vKdLz@laptok> Message-ID: <1361104231.FzJSUPpjIn@inhell> On Saturday 16 of February 2013 19:25:03 ?ukasz Ma?ko wrote: > What is wrong with your KDE after upgrade? Any details? kwin was crashing. I had to come back to have a usable desktop. -- ?ukasz G??bicki mail/rot13:yhxnfmty at cbfg.cy PLD/Linux Team gg:246267 Linux Registered User #318551 blekot:{irc,skype} From arekm at maven.pl Sun Feb 17 12:23:58 2013 From: arekm at maven.pl (Arkadiusz =?utf-8?q?Mi=C5=9Bkiewicz?=) Date: Sun, 17 Feb 2013 12:23:58 +0100 Subject: amarok In-Reply-To: <1361104231.FzJSUPpjIn@inhell> References: <25208390.novHtiWRFd@inhell> <45371500.mD3d3vKdLz@laptok> <1361104231.FzJSUPpjIn@inhell> Message-ID: <201302171223.59079.arekm@maven.pl> On Sunday 17 of February 2013, Lukasz Glebicki wrote: > On Saturday 16 of February 2013 19:25:03 ?ukasz Ma?ko wrote: > > What is wrong with your KDE after upgrade? Any details? > > kwin was crashing. I had to come back to have a usable desktop. Here taskbar was taking down whole plasma. Removing taskbar manually from config files, running kde and readding it from kde fixed the problem. -- Arkadiusz Mi?kiewicz, arekm / maven.pl From glen at pld-linux.org Sun Feb 17 12:50:38 2013 From: glen at pld-linux.org (=?UTF-8?Q?Elan_Ruusam=C3=A4e?=) Date: Sun, 17 Feb 2013 13:50:38 +0200 Subject: clang Message-ID: <2e26d9d50860df0d12e42e609bb30633@delfi.ee> is pld clang broken? it does not seem to find it's own headers glen at carme-pld diskdev_cmds-540.1.linux3/BlocksRunTime $ cat test.c #include glen at carme-pld diskdev_cmds-540.1.linux3/BlocksRunTime $ clang test.c test.c:2:10: fatal error: 'stdbool.h' file not found #include ^ 1 error generated. glen at carme-pld diskdev_cmds-540.1.linux3/BlocksRunTime $ rpm -ql clang|grep stddef.h /usr/lib64/clang/3.2/include/stddef.h -- glen From lukaszgl at post.pl Sun Feb 17 13:18:46 2013 From: lukaszgl at post.pl (Lukasz Glebicki) Date: Sun, 17 Feb 2013 13:18:46 +0100 Subject: amarok In-Reply-To: <201302171223.59079.arekm@maven.pl> References: <25208390.novHtiWRFd@inhell> <1361104231.FzJSUPpjIn@inhell> <201302171223.59079.arekm@maven.pl> Message-ID: <3564839.0qPVK4g4mx@inhell> On Sunday 17 of February 2013 12:23:58 Arkadiusz Mi?kiewicz wrote: > Here taskbar was taking down whole plasma. Removing taskbar manually from > config files, running kde and readding it from kde fixed the problem. I removed kwin config file and it seems that everything is ok now. Regards -- ?ukasz G??bicki mail/rot13:yhxnfmty at cbfg.cy PLD/Linux Team gg:246267 Linux Registered User #318551 blekot:{irc,skype} From ed at yen.ipipan.waw.pl Sun Feb 17 13:19:05 2013 From: ed at yen.ipipan.waw.pl (=?UTF-8?Q?=C5=81ukasz_Ma=C5=9Bko?=) Date: Sun, 17 Feb 2013 13:19:05 +0100 Subject: amarok In-Reply-To: <201302171223.59079.arekm@maven.pl> References: <25208390.novHtiWRFd@inhell> <45371500.mD3d3vKdLz@laptok> <1361104231.FzJSUPpjIn@inhell> <201302171223.59079.arekm@maven.pl> Message-ID: <635de84a-1aa6-4ba5-9b05-47fd6442e6a6@email.android.com> "Arkadiusz Mi?kiewicz" napisa?: >On Sunday 17 of February 2013, Lukasz Glebicki wrote: >> On Saturday 16 of February 2013 19:25:03 ?ukasz Ma?ko wrote: >> > What is wrong with your KDE after upgrade? Any details? >> >> kwin was crashing. I had to come back to have a usable desktop. > >Here taskbar was taking down whole plasma. Removing taskbar manually >from >config files, running kde and readding it from kde fixed the problem. > >-- >Arkadiusz Mi?kiewicz, arekm / maven.pl >_______________________________________________ >pld-devel-en mailing list >pld-devel-en at lists.pld-linux.org >http://lists.pld-linux.org/mailman/listinfo/pld-devel-en In my case, I've noticed no problems. Migration from 4.9 was just an update. Arch i686, all other packages from latest Th+test+ready. From qboosh at pld-linux.org Sun Feb 17 15:37:21 2013 From: qboosh at pld-linux.org (Jakub Bogusz) Date: Sun, 17 Feb 2013 15:37:21 +0100 Subject: clang In-Reply-To: <2e26d9d50860df0d12e42e609bb30633@delfi.ee> References: <2e26d9d50860df0d12e42e609bb30633@delfi.ee> Message-ID: <20130217143721.GA9208@mail> On Sun, Feb 17, 2013 at 01:50:38PM +0200, Elan Ruusam?e wrote: > is pld clang broken? it does not seem to find it's own headers > > glen at carme-pld diskdev_cmds-540.1.linux3/BlocksRunTime $ cat test.c > #include > > glen at carme-pld diskdev_cmds-540.1.linux3/BlocksRunTime $ clang test.c > test.c:2:10: fatal error: 'stdbool.h' file not found > #include > ^ > 1 error generated. > > glen at carme-pld diskdev_cmds-540.1.linux3/BlocksRunTime $ rpm -ql > clang|grep stddef.h > /usr/lib64/clang/3.2/include/stddef.h I think I finally found where this path comes from. Please check release 3. -- Jakub Bogusz http://qboosh.pl/ From glen at pld-linux.org Mon Feb 18 10:48:27 2013 From: glen at pld-linux.org (=?UTF-8?B?RWxhbiBSdXVzYW3DpGU=?=) Date: Mon, 18 Feb 2013 11:48:27 +0200 Subject: [packages/bash-completion] - build fix In-Reply-To: <0113649bc4feb08040f32c567044c1f9ba942350_refs_heads_master@pld-linux.org> References: <0b9f2c011bc50e895ef31f11fdec54a0556991bd_refs_heads_master@pld-linux.org> <0113649bc4feb08040f32c567044c1f9ba942350_refs_heads_master@pld-linux.org> Message-ID: <5121F8EB.5050200@pld-linux.org> On 17.02.2013 01:20, arekm wrote: > commit 0113649bc4feb08040f32c567044c1f9ba942350 > Author: Arkadiusz Mi?kiewicz > Date: Sun Feb 17 00:20:13 2013 +0100 > > - build fix > > bash-completion.spec | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > --- > diff --git a/bash-completion.spec b/bash-completion.spec > index 51263e2..bc5a28a 100644 > --- a/bash-completion.spec > +++ b/bash-completion.spec > @@ -41,7 +41,7 @@ dope?nianie parametr?w linii polece?. > > %prep > %setup -q > -cp -p %{SOURCE4} completions/pear > +cp -p '%{SOURCE4}' completions/pear > %patch0 -p1 > %patch1 -p1 eee, eek? if the error was because sourcedir contained space, then 99.99% of our specs are broken what was the error? -- glen From arekm at maven.pl Mon Feb 18 10:52:34 2013 From: arekm at maven.pl (Arkadiusz =?utf-8?q?Mi=C5=9Bkiewicz?=) Date: Mon, 18 Feb 2013 10:52:34 +0100 Subject: [packages/bash-completion] - build fix In-Reply-To: <5121F8EB.5050200@pld-linux.org> References: <0b9f2c011bc50e895ef31f11fdec54a0556991bd_refs_heads_master@pld-linux.org> <0113649bc4feb08040f32c567044c1f9ba942350_refs_heads_master@pld-linux.org> <5121F8EB.5050200@pld-linux.org> Message-ID: <201302181052.34544.arekm@maven.pl> On Monday 18 of February 2013, Elan Ruusam?e wrote: > On 17.02.2013 01:20, arekm wrote: > > commit 0113649bc4feb08040f32c567044c1f9ba942350 > > Author: Arkadiusz Mi?kiewicz > > Date: Sun Feb 17 00:20:13 2013 +0100 > > > > - build fix > > > > bash-completion.spec | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > --- > > diff --git a/bash-completion.spec b/bash-completion.spec > > index 51263e2..bc5a28a 100644 > > --- a/bash-completion.spec > > +++ b/bash-completion.spec > > @@ -41,7 +41,7 @@ dope?nianie parametr?w linii polece?. > > > > %prep > > %setup -q > > > > -cp -p %{SOURCE4} completions/pear > > +cp -p '%{SOURCE4}' completions/pear > > > > %patch0 -p1 > > %patch1 -p1 > > eee, eek? if the error was because sourcedir contained space, then > 99.99% of our specs are broken > > what was the error? SOURCE4 name contains & character -- Arkadiusz Mi?kiewicz, arekm / maven.pl From glen at pld-linux.org Mon Feb 18 11:48:31 2013 From: glen at pld-linux.org (=?UTF-8?B?RWxhbiBSdXVzYW3DpGU=?=) Date: Mon, 18 Feb 2013 12:48:31 +0200 Subject: [packages/bash-completion] - build fix In-Reply-To: <201302181052.34544.arekm@maven.pl> References: <0b9f2c011bc50e895ef31f11fdec54a0556991bd_refs_heads_master@pld-linux.org> <0113649bc4feb08040f32c567044c1f9ba942350_refs_heads_master@pld-linux.org> <5121F8EB.5050200@pld-linux.org> <201302181052.34544.arekm@maven.pl> Message-ID: <512206FF.5070205@pld-linux.org> On 18.02.2013 11:52, Arkadiusz Mi?kiewicz wrote: > On Monday 18 of February 2013, Elan Ruusam?e wrote: >> On 17.02.2013 01:20, arekm wrote: >>> commit 0113649bc4feb08040f32c567044c1f9ba942350 >>> Author: Arkadiusz Mi?kiewicz >>> Date: Sun Feb 17 00:20:13 2013 +0100 >>> >>> - build fix >>> >>> bash-completion.spec | 2 +- >>> 1 file changed, 1 insertion(+), 1 deletion(-) >>> >>> --- >>> diff --git a/bash-completion.spec b/bash-completion.spec >>> index 51263e2..bc5a28a 100644 >>> --- a/bash-completion.spec >>> +++ b/bash-completion.spec >>> @@ -41,7 +41,7 @@ dope?nianie parametr?w linii polece?. >>> >>> %prep >>> %setup -q >>> >>> -cp -p %{SOURCE4} completions/pear >>> +cp -p '%{SOURCE4}' completions/pear >>> >>> %patch0 -p1 >>> %patch1 -p1 >> eee, eek? if the error was because sourcedir contained space, then >> 99.99% of our specs are broken >> >> what was the error? > SOURCE4 name contains & character > rpm 5 treats '#' as comment (at least on SourceX lines), you must use different hack here: Source4: http://svn.php.net/viewvc/pear2/sandbox/PEAR_BashCompletion/trunk/pear?revision=285425&view=co#/pear -> Source4: http://svn.php.net/viewvc/pear2/sandbox/PEAR_BashCompletion/trunk/pear?revision=285425&view=co&/pear -- glen From arekm at maven.pl Mon Feb 18 11:50:51 2013 From: arekm at maven.pl (Arkadiusz =?utf-8?q?Mi=C5=9Bkiewicz?=) Date: Mon, 18 Feb 2013 11:50:51 +0100 Subject: [packages/bash-completion] - build fix In-Reply-To: <512206FF.5070205@pld-linux.org> References: <0b9f2c011bc50e895ef31f11fdec54a0556991bd_refs_heads_master@pld-linux.org> <201302181052.34544.arekm@maven.pl> <512206FF.5070205@pld-linux.org> Message-ID: <201302181150.51690.arekm@maven.pl> On Monday 18 of February 2013, Elan Ruusam?e wrote: > On 18.02.2013 11:52, Arkadiusz Mi?kiewicz wrote: > > On Monday 18 of February 2013, Elan Ruusam?e wrote: > >> On 17.02.2013 01:20, arekm wrote: > >>> commit 0113649bc4feb08040f32c567044c1f9ba942350 > >>> Author: Arkadiusz Mi?kiewicz > >>> Date: Sun Feb 17 00:20:13 2013 +0100 > >>> > >>> - build fix > >>> > >>> bash-completion.spec | 2 +- > >>> 1 file changed, 1 insertion(+), 1 deletion(-) > >>> > >>> --- > >>> diff --git a/bash-completion.spec b/bash-completion.spec > >>> index 51263e2..bc5a28a 100644 > >>> --- a/bash-completion.spec > >>> +++ b/bash-completion.spec > >>> @@ -41,7 +41,7 @@ dope?nianie parametr?w linii polece?. > >>> > >>> %prep > >>> %setup -q > >>> > >>> -cp -p %{SOURCE4} completions/pear > >>> +cp -p '%{SOURCE4}' completions/pear > >>> > >>> %patch0 -p1 > >>> %patch1 -p1 > >> > >> eee, eek? if the error was because sourcedir contained space, then > >> 99.99% of our specs are broken > >> > >> what was the error? > > > > SOURCE4 name contains & character > > rpm 5 treats '#' as comment (at least on SourceX lines), you must use > different hack here: cp -p '%{SOURCE4}' works fine, too for this particular issue I had. -- Arkadiusz Mi?kiewicz, arekm / maven.pl From glen at pld-linux.org Mon Feb 18 12:05:47 2013 From: glen at pld-linux.org (=?UTF-8?B?RWxhbiBSdXVzYW3DpGU=?=) Date: Mon, 18 Feb 2013 13:05:47 +0200 Subject: [packages/bash-completion] - build fix In-Reply-To: <201302181150.51690.arekm@maven.pl> References: <0b9f2c011bc50e895ef31f11fdec54a0556991bd_refs_heads_master@pld-linux.org> <201302181052.34544.arekm@maven.pl> <512206FF.5070205@pld-linux.org> <201302181150.51690.arekm@maven.pl> Message-ID: <51220B0B.1060209@pld-linux.org> On 18.02.2013 12:50, Arkadiusz Mi?kiewicz wrote: > On Monday 18 of February 2013, Elan Ruusam?e wrote: >> On 18.02.2013 11:52, Arkadiusz Mi?kiewicz wrote: >>> On Monday 18 of February 2013, Elan Ruusam?e wrote: >>>> On 17.02.2013 01:20, arekm wrote: >>>>> commit 0113649bc4feb08040f32c567044c1f9ba942350 >>>>> Author: Arkadiusz Mi?kiewicz >>>>> Date: Sun Feb 17 00:20:13 2013 +0100 >>>>> >>>>> - build fix >>>>> >>>>> bash-completion.spec | 2 +- >>>>> 1 file changed, 1 insertion(+), 1 deletion(-) >>>>> >>>>> --- >>>>> diff --git a/bash-completion.spec b/bash-completion.spec >>>>> index 51263e2..bc5a28a 100644 >>>>> --- a/bash-completion.spec >>>>> +++ b/bash-completion.spec >>>>> @@ -41,7 +41,7 @@ dope?nianie parametr?w linii polece?. >>>>> >>>>> %prep >>>>> %setup -q >>>>> >>>>> -cp -p %{SOURCE4} completions/pear >>>>> +cp -p '%{SOURCE4}' completions/pear >>>>> >>>>> %patch0 -p1 >>>>> %patch1 -p1 >>>> eee, eek? if the error was because sourcedir contained space, then >>>> 99.99% of our specs are broken >>>> >>>> what was the error? >>> SOURCE4 name contains & character >> rpm 5 treats '#' as comment (at least on SourceX lines), you must use >> different hack here: > cp -p '%{SOURCE4}' works fine, too for this particular issue I had. > basename-rename-hack is more consistent, it keeps the originally intended filename, i.e "pear" not name what you got: " pear?revision=285425&view=co" you fixed only shell quoting, but rpmbuild takes filenames by cutting out from last slash. and the basename is also used when fetching from distfiles, currently you were lucky as query-string part (?revision=285425&view=co) is ignored when fetching from distfiles via ftp. -- glen From glen at pld-linux.org Mon Feb 18 12:17:20 2013 From: glen at pld-linux.org (=?ISO-8859-1?Q?Elan_Ruusam=E4e?=) Date: Mon, 18 Feb 2013 13:17:20 +0200 Subject: clang In-Reply-To: <20130217143721.GA9208@mail> References: <2e26d9d50860df0d12e42e609bb30633@delfi.ee> <20130217143721.GA9208@mail> Message-ID: <51220DC0.8020101@pld-linux.org> On 17.02.2013 16:37, Jakub Bogusz wrote: > On Sun, Feb 17, 2013 at 01:50:38PM +0200, Elan Ruusam?e wrote: >> is pld clang broken? it does not seem to find it's own headers >> >> glen at carme-pld diskdev_cmds-540.1.linux3/BlocksRunTime $ cat test.c >> #include >> >> glen at carme-pld diskdev_cmds-540.1.linux3/BlocksRunTime $ clang test.c >> test.c:2:10: fatal error: 'stdbool.h' file not found >> #include >> ^ >> 1 error generated. >> >> glen at carme-pld diskdev_cmds-540.1.linux3/BlocksRunTime $ rpm -ql >> clang|grep stddef.h >> /usr/lib64/clang/3.2/include/stddef.h > I think I finally found where this path comes from. > Please check release 3. it is ok now. -- glen From masko at ipipan.waw.pl Sun Feb 17 13:12:23 2013 From: masko at ipipan.waw.pl (=?UTF-8?Q?=C5=81ukasz_Ma=C5=9Bko?=) Date: Sun, 17 Feb 2013 13:12:23 +0100 Subject: amarok In-Reply-To: <201302171223.59079.arekm@maven.pl> References: <25208390.novHtiWRFd@inhell> <45371500.mD3d3vKdLz@laptok> <1361104231.FzJSUPpjIn@inhell> <201302171223.59079.arekm@maven.pl> Message-ID: In my case, I've noticed no problems. Migration from 4.9 was just an update. Arch i686, all other packages from latest Th+test+ready. "Arkadiusz Mi?kiewicz" napisa?: >On Sunday 17 of February 2013, Lukasz Glebicki wrote: >> On Saturday 16 of February 2013 19:25:03 ?ukasz Ma?ko wrote: >> > What is wrong with your KDE after upgrade? Any details? >> >> kwin was crashing. I had to come back to have a usable desktop. > >Here taskbar was taking down whole plasma. Removing taskbar manually >from >config files, running kde and readding it from kde fixed the problem. > >-- >Arkadiusz Mi?kiewicz, arekm / maven.pl >_______________________________________________ >pld-devel-en mailing list >pld-devel-en at lists.pld-linux.org >http://lists.pld-linux.org/mailman/listinfo/pld-devel-en -- Pozdrawiam. ?ukasz Ma?ko Wys?ane za pomoc? K-9 Mail. From glen at pld-linux.org Wed Feb 27 22:20:39 2013 From: glen at pld-linux.org (=?UTF-8?Q?Elan_Ruusam=C3=A4e?=) Date: Wed, 27 Feb 2013 23:20:39 +0200 Subject: Mesa "undesirable files" Message-ID: <28663952fc20f09f91f866127c8adbaf@delfi.ee> why are these files "undesirable"? # strip out undesirable headers %{__rm} $RPM_BUILD_ROOT%{_includedir}/GL/{wglext,wmesa}.h https://github.com/pld-linux/Mesa/blob/1f4ce745921058c9955443eab64e3c7ef0a063fd/Mesa.spec#L1047 tracing the origin of it, is not helpful either: https://github.com/pld-linux/Mesa/commit/c885f99e5db1c58085166b7804cb0a0e9982b242 https://github.com/pld-linux/Mesa/commit/59f12de82554d1626506295b0940daca16338a6e -- glen From qboosh at pld-linux.org Thu Feb 28 06:24:34 2013 From: qboosh at pld-linux.org (Jakub Bogusz) Date: Thu, 28 Feb 2013 06:24:34 +0100 Subject: Mesa "undesirable files" In-Reply-To: <28663952fc20f09f91f866127c8adbaf@delfi.ee> References: <28663952fc20f09f91f866127c8adbaf@delfi.ee> Message-ID: <20130228052434.GA28628@mail> On Wed, Feb 27, 2013 at 11:20:39PM +0200, Elan Ruusam?e wrote: > why are these files "undesirable"? > > # strip out undesirable headers > %{__rm} $RPM_BUILD_ROOT%{_includedir}/GL/{wglext,wmesa}.h > https://github.com/pld-linux/Mesa/blob/1f4ce745921058c9955443eab64e3c7ef0a063fd/Mesa.spec#L1047 Specific to other operating system (WGL is Windows equivalent of GLX, wglext.h an equivalent of glxext.h). -- Jakub Bogusz http://qboosh.pl/