Getting quicker fixes for issues that affect distro packages only

33 views
Skip to first unread message

Evangelos Foutras

unread,
Jan 24, 2015, 6:56:10 AM1/24/15
to chromium-...@chromium.org
The following issue occurs only with ICU 54.1 which isn't what Chrome
ships with:

https://code.google.com/p/chromium/issues/detail?id=445075#c10

Therefore, only distro packages that link to the system ICU (and that
being version 54.1) are affected. (Arch is one of them. [1])

The general response to such issues, especially when no debugging info
is provided, is "Unable to reproduce the issue [with Chrome], please
provide a Crash ID". Even if relevant information is posted, the issue
remains in a zombie state for a while.

For the particular issue above, I've posted detailed information about
what must be causing these crashes, but there hasn't been any update
since my comment.

As a package maintainer, I have two options in this case:

1) Build with the bundled ICU. (This would be sub-optimal.)
2) Try and fix the issue myself and submit a patch for review.

I've done (2) in the past once or twice but the process isn't very
straightforward for a non-regular contributor like me. For this
particular bug, however, I'm not sure if passing the correct "capacity"
value to uscript_getScriptExtensions() is enough, or whether the size of
scriptExtensions needs to be increased to accommodate more scripts.

Is there anything we can do for such requests to be handled more
efficiently?

[1] https://bugs.archlinux.org/task/43330

Michael Gilbert

unread,
Jan 24, 2015, 11:19:56 AM1/24/15
to chromium-...@chromium.org
On Sat, Jan 24, 2015 at 6:56 AM, Evangelos Foutras wrote:
> Is there anything we can do for such requests to be handled more
> efficiently?

What may help is for crbug to recognize distro packagers, and for
chromium devs to pay more attention to issues reported by them.

Bug tracking systems that use real email addresses rather than gmail
implicitly make distro contributors clear, and that is entirely
missing from crbug.

Also, maybe using this list instead of crbug for forwarding and
discussing distro bugs may help.

Best wishes,
Mike

Torne (Richard Coles)

unread,
Jan 26, 2015, 10:51:28 AM1/26/15
to Michael Gilbert, chromium-...@chromium.org
On Sat Jan 24 2015 at 16:19:57 Michael Gilbert <mgil...@debian.org> wrote:
On Sat, Jan 24, 2015 at 6:56 AM, Evangelos Foutras wrote:
> Is there anything we can do for such requests to be handled more
> efficiently?

What may help is for crbug to recognize distro packagers, and for
chromium devs to pay more attention to issues reported by them.

Bug tracking systems that use real email addresses rather than gmail
implicitly make distro contributors clear, and that is entirely
missing from crbug.

You can use any email address you like for crbug; it just requires a Google account (which can be associated with any email), not a Gmail account.
 
Also, maybe using this list instead of crbug for forwarding and
discussing distro bugs may help.

Best wishes,
Mike

--
You received this message because you are subscribed to the Google Groups "chromium-packagers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to chromium-packagers+unsub...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-packagers/CANTw%3DMP7eHwHbwawmirQAPR1oOzaj33i8FR1GsA-X_3qmg_UTg%40mail.gmail.com.

Paweł Hajdan, Jr.

unread,
Jan 26, 2015, 12:04:51 PM1/26/15
to Torne (Richard Coles), Michael Gilbert, chromium-...@chromium.org
Even though it's Chromium-only so far, looks like we could still use a clear list of repro steps. Looks like it's just "visit http://hi.wikipedia.org/", but I only see it in the Arch tracker, not the Chromium tracker.

Please upload the patch for review, I think the reviewer can help with determining whether it's correct and complete.

This list was intended to help with cases like this. Don't hesitate to post further questions, including about the contributing patch process.

Finally, given that Gentoo also uses system ICU, it's likely affected by the same issue. I may look further into this if needed.

Paweł

To unsubscribe from this group and stop receiving emails from it, send an email to chromium-packag...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-packagers/CAEV-rjefS8nrwssmEKxxTVUQaLbP%2BXAJkW-twKLQ%2B_Zqfru%2B2Q%40mail.gmail.com.

Evangelos Foutras

unread,
Jan 26, 2015, 12:34:04 PM1/26/15
to "Paweł Hajdan, Jr.", Torne (Richard Coles), Michael Gilbert, chromium-...@chromium.org
I've uploaded the patch for review at:
https://codereview.chromium.org/868393002

Please note that the crash occurs only with ICU 54.1 (previous versions
would return few script codes and wouldn't trigger the buffer
overflow). Therefore, you won't be able to reproduce it on Gentoo which
has ICU 53.1 AFAICS.

By the way, my original question has mostly been answered; using this
list to discuss distro issues seems to be our best bet.

Raymond Wooninck

unread,
Feb 15, 2015, 5:56:50 AM2/15/15
to chromium-...@chromium.org, Paweł Hajdan, Jr.
Hi Guys,

I guess those that are close to debian packaging, wouldn't see this issue, but
with the latest Chromium dev channel the remoting part seems to be hardcoded
to depend on the debian architecture.

Building it delivers the following error:
[ 339s] + ./build/gyp_chromium build/all.gyp --depth . -Dwerror= -
Dlinux_sandbox_chrome_path=/usr/lib64/chromium/chromium -Ddisable_nacl=1 -
Denable_remoting_host=0 -Darchive_chromoting_tests=0 -Duse_openssl=0 -
Dproprietary_codecs=1 -Duse_system_ffmpeg=0 -Dbuild_ffmpegsumo=1 -
Dremove_webcore_debug_symbols=1 -Dlogging_like_official_build=1 -
Dclang_use_chrome_plugins=0 -Dlinux_fpic=1 -Dtoolkit_uses_gtk=0 -
Dtarget_arch=x64 -Dsystem_libdir=lib64 -Dclang=0 -Djavascript_engine=v8 -
Dpython_ver=2.7 -Dcomponent=shared_library -Dlinux_use_gold_binary=0 -
Dlinux_use_gold_flags=0 -
Dgoogle_api_key=AIzaSyD1hTe85_a14kr1Ks8T3Ce75rvbR1_Dx7Q -
Dgoogle_default_client_id=4139804441.apps.googleusercontent.com -
Dgoogle_default_client_secret=KDTRKEZk2jwT_7CDpcmMA--P
[ 341s] Updating projects from gyp files...
[ 347s] host/installer/linux/build-deb.sh: line 9: dpkg-architecture: command
not found
[ 347s] gyp: Call to '['host/installer/linux/build-deb.sh', '-p', '-s',
'..']' returned exit status 0.
[ 366s] error: Bad exit status from /var/tmp/rpm-tmp.75gjwL (%build)

Is there any flag that I can use to prevent build-deb.sh to be executed ? Or
do I have to patch this one out ?

Thanks

Regards

Raymond

Mike Frysinger

unread,
Feb 15, 2015, 6:54:15 AM2/15/15
to Raymond Wooninck, chromium-...@chromium.org, Paweł Hajdan, Jr.
i wonder if you're building pre-revert of https://codereview.chromium.org/905223002/
-mike


Raymond

--
You received this message because you are subscribed to the Google Groups "chromium-packagers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to chromium-packag...@chromium.org.

Raymond Wooninck

unread,
Feb 15, 2015, 7:14:14 AM2/15/15
to Mike Frysinger, chromium-...@chromium.org, Paweł Hajdan, Jr.
On Sunday 15 February 2015 06:53:53 Mike Frysinger wrote:
> i wonder if you're building pre-revert of
> https://codereview.chromium.org/905223002/
> -mike
>
Hi Mike,

Thanks for pointing this one out. I am building the released tarball (as
created by Pawel". The tarball is 42.0.2298.0 which was released last thursday
as an Dev Channel Update.

Regards

Raymond

Paweł Hajdan, Jr.

unread,
Feb 17, 2015, 11:38:09 AM2/17/15
to Raymond Wooninck, Mike Frysinger, chromium-...@chromium.org
Since the CLs are getting reverted, I prefer to wait until things stabilize src-side. I'll definitely take a look at the next dev channel bump in Gentoo.

Paweł

Gary Gatling

unread,
Feb 17, 2015, 11:54:44 AM2/17/15
to Raymond Wooninck, chromium-...@chromium.org, Paweł Hajdan, Jr.
On Sun, Feb 15, 2015 at 5:56 AM, Raymond Wooninck <titti...@gmail.com> wrote:
Hi Guys,

I guess those that are close to debian packaging, wouldn't see this issue, but
with the latest Chromium dev channel the remoting part seems to be hardcoded
to depend on the debian architecture.\

I am seeing this also when trying to make rpms for fedora and rhel for my third party yum repo.

I had to add:

%if "%{?version:%{version}}%{!?version:0}" >= "42.0.2298.0"
BuildRequires:  dpkg-devel
%endif

to get it to compile. I guess some of the debian tools are available from fedora/epel which helps me out with this situation.

I also had to add:

%if "%{?version:%{version}}%{!?version:0}" < "42.0.2298.0"
cp -a libpdf.so %{buildroot}%{chromium_path}
%endif


and

%if "%{?version:%{version}}%{!?version:0}" < "42.0.2298.0"
/%{chromium_path}/libpdf.so
%endif


Is it normal that libpdf.so is not there any longer beginning with 42.0.2298.0 ?

Thanks,


 

Lei Zhang

unread,
Feb 17, 2015, 12:16:56 PM2/17/15
to Gary Gatling, Raymond Wooninck, chromium-...@chromium.org, Paweł Hajdan, Jr.
Yes, since the PDF code is open source now, there's no need for it to
live as a separate binary.
> --
> You received this message because you are subscribed to the Google Groups
> "chromium-packagers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to chromium-packag...@chromium.org.
> To view this discussion on the web visit
> https://groups.google.com/a/chromium.org/d/msgid/chromium-packagers/CAG5Ck-5gg%3DCk5UAuC%2BZ7vW7ow_9dk545m2aQG0Y70Ltf4YC85g%40mail.gmail.com.

Raymond Wooninck

unread,
Feb 17, 2015, 3:29:07 PM2/17/15
to chromium-...@chromium.org
On Tuesday, February 17, 2015 05:37:48 PM Paweł Hajdan, Jr. wrote:
> Since the CLs are getting reverted, I prefer to wait until things stabilize
> src-side. I'll definitely take a look at the next dev channel bump in
> Gentoo.
>
Hi Pawel,

I took one of the later chromium tarballs and this one compiled fine. So I
guess that the official Dev Channel tarball was just bad timed and in the
middle of some reverts :)

The next one should be fine.

Regards
Raymond
Reply all
Reply to author
Forward
0 new messages