Firefox 85 fails to print with filter failed error in CUPS (Brother MFC7360N)
Categories
(Core :: Printing: Output, defect)
Tracking
()
Tracking | Status | |
---|---|---|
firefox-esr78 | --- | unaffected |
firefox86 | --- | wontfix |
firefox87 | --- | fixed |
firefox88 | --- | fixed |
People
(Reporter: w.hawes, Assigned: emilio)
References
(Regressed 1 open bug, Regression)
Details
(Keywords: regression)
Attachments
(2 files)
(deleted),
text/x-phabricator-request
|
RyanVM
:
approval-mozilla-beta+
|
Details |
(deleted),
text/plain
|
Details |
User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:85.0) Gecko/20100101 Firefox/85.0
Steps to reproduce:
Try to print any page from Firefox to a Brother MFC7360N printer through CUPS on a Linux system, using the generic CUPSwrapper provided by Brother
Actual results:
Print job fails with a "filter failed" message.
CUPS error log shows these messages:
D [09/Feb/2021:10:12:28 -0500] [Job 828] Can't use an undefined value as a subroutine reference at /usr/lib/cups/filter/brother_lpdwrapper_BrGenML1 line 565.
D [09/Feb/2021:10:12:28 -0500] [Job 828] PID 17699 (/usr/lib/cups/filter/brother_lpdwrapper_BrGenML1) stopped with status 255 (Unknown error 155)
Analysis of the lpdwrapper perl script found that the failure is due to a missing unit (e.g. mm, in, pt) at the end of a custom pagesize. Firefox has passed the page size (US letter) as this:
D [09/Feb/2021:10:12:28 -0500] [Job 828] argv[5]="PageSize=Custom.612.00x792.00 Collate Duplex=None job-uuid=urn:uuid:b1ae6b38-c125-3711-62c0-2aa4db7fac70 job-originating-host-name=localhost date-time-at-creation= date-time-at-processing= time-at-creation=1612883548 time-at-processing=1612883548"
The 612x792 size is the US letter size in points and the wrapper script was expecting a 'pt' at the end. When specifying a custom page size, Firefox should put the units abbreviation at the end.
As a workaround, the problem can be patched by making the lpdwrapper perl script default to 'pt' on custom page sizes.
The failure was consistent on all pages tried, and for all paper sizes tested.
Expected results:
Page should have printed normally. Printing from Firefox used to work on my system, but the failure started sometime around Firefox 84.0.2, and continues with 85.0.
Comment 1•4 years ago
|
||
The Bugbug bot thinks this bug should belong to the 'Toolkit::Printing' component, and is moving the bug to that component. Please revert this change in case you think the bot is wrong.
Comment 2•4 years ago
|
||
Hi Bill, I had printing problems in 75.0 but not in 85.0.1, is your Firefox 85.0 or 85.0.1?
I described my problem here(which mozilla archived without even trying to solve the problem)
https://support.mozilla.org/en-US/questions/1285212#answer-1309224
Did you fix your problem?
I have read numerous threads now and not only on this site, where this bug seem to jump between versions and OS, so it would be nice if mozilla could get this one fixed. Maybe on my next update the problem will be back, who knows:(
Jan
Hi Jan,
I first saw the problem in Firefox 84.0.2, and when it persisted in 85.0 I filed the report. It's likely that the problem appeared when the Firefox printing subsystem started mapping all page sizes (letter, legal, A4, etc.) to a custom size in points. It's not clear to me why this change was made, or even whether it was intentional, as the list of supported page sizes comes from the printer definition and so should be handled correctly by all printers. Using a custom page size means that seldom used and probably poorly tested parts of the printer driver layer are now being used for every printing job. I'm hoping that someone familiar with the Firefox printing kit will weigh in with a rationale for the custom page size switch. FWIW, Chrome passes the page size as letter, A4, etc.
I couldn't find a clear specification of the custom page size option in the CUPS documentation, but the docs for the lp command include an example with a custom page size in points without a unit spec, implying that dimensions in points are the intended default. If this is the case, the current behavior of Firefox is not actually incorrect, only misguided.
I fixed the problem in my system with a patch to the cupswrapper perl script supplied by Brother. I'm planning to send the changes to Brother (if they're interested), and could post a patch here if anyone needs it.
Bill
Comment 4•4 years ago
|
||
Seems to me that we are using a pretty nroaml GTK API for this in nsPrintSettingsGTK::SetPaperId? https://searchfox.org/mozilla-central/rev/8432d4fe31245ae9121231d7c0335aaa342675d2/widget/gtk/nsPrintSettingsGTK.cpp#411. Maybe we should try to use built-in paper-sizes that match in size.
Assignee | ||
Comment 5•4 years ago
|
||
Yeah, we're using GTK for this, so this is quite odd. Might be an upstream gtk bug but we could probably work around it... Is there any chance you could use mozregression
to see when this regressed? You should be able to do this with something like mozregression --good 83 --bad 84
. If not let me know and I can try to figure out how to figure out if a job is good or bad without the relevant hardware.
I'll take a look at mozregression to see if I can use it here ..
However, it may possible to check for this problem on any system with CUPS, without having the specific failing printer installed. It looks like the CUPS error log is showing the parameters being passed from the application layer to whatever printer is selected. Try setting Loglevel to debug in the CUPS config file, then print a page. Search the error log for argv[5 and if it shows a custom page size in the parameter list, that's the condition that triggered this failure.
I do want to note that the custom page size being passed does change if you select a different paper size, so the printing kit is not ignoring the user's selection.
Hi Emilio,
I downloaded mozregression and tested some builds .. seems like a very useful tool!
The results were a bit unexpected but hopefully useful .. seven builds tested between 2020-09-26 and 2020-11-02 all emitted custom page sizes and would have triggered the failure. Three builds tested from 9/7, 9/21, and 9/24 were not able to put up the print review dialog -- it just hung with a blank page -- so no further testing was possible.
So based on this I would guess that there was a major overhaul of the printing toolkit in progress during September 2020, and when the smoke cleared the page size had switched to custom. Since most printers handle the custom size correctly, nobody reported any problems until quite a while later. (I don't need to print from Firefox all that often.)
Bill
Assignee | ||
Comment 8•4 years ago
|
||
Thanks for the comments! There are some tricks that could be pulled up to bisect around those dates, I suspect flipping print.tab_modal.enabled could come up with a print dialog. Let me try to figure out what caused this using the cups log.
Assignee | ||
Comment 9•4 years ago
|
||
Ok, so I finally took some time to do this. Bisected down to:
For my own future reference, the bisection method has basically been looking at the spool files in /var/spool/cups
like this, since journalct didn't show all the job details like your logs:
$ while true; do strings c<job-id> | rg -C 1 PageSize; if [ $? -eq 0 ]; then break; fi; sleep 1; done
So this looks like a regression from bug 1660527.
Updated•4 years ago
|
Assignee | ||
Comment 10•4 years ago
|
||
So we have a pre-existing workaround which is somehow not actually working.
This is all sad, this comes from bug 414314, one would've hoped print driver bugs would have been fixed by now :-)
Assignee | ||
Updated•4 years ago
|
Assignee | ||
Updated•4 years ago
|
Assignee | ||
Comment 11•4 years ago
|
||
Due to a rounding issue in gtk_paper_size_new1, we were ending up with
a custom page size regardless, which causes issues with some printers.
Instead, use the gtk_paper_size_new_from_ipp, which is available in all
gtk versions we support, works nicely for our use case, has some
tolerance for minor floating point rounding issues, and should also get
a nicer codepath than the custom page size.
Before bug 1660527 we were using the printer settings, which had a paper
size created from gtk itself without parsing the ipp header, so we were
getting the happy path.
Assignee | ||
Comment 12•4 years ago
|
||
This was all supposed to work after all, but turns out a rounding issue in GTK caused it not to work. Sadness.
https://treeherder.mozilla.org/#/jobs?repo=try&revision=1590390fe40771fdde6a5b6233a22c3444631769 should have a build in about an hour or so (click on the "B", then go to the "Artifacts" tab, then you can download a tarball with a Firefox binary). Could you check that build works for you?
Also, if you could contact the support for your printer pointing to this bug it'd be greatly appreciated! That way they can hopefully fix it in the future :)
Thanks!
Assignee | ||
Updated•4 years ago
|
Reporter | ||
Comment 13•4 years ago
|
||
Hi Emilio,
Excellent, glad to see you were able to track it down so quickly! Once Firefox reverts to using native page sizes, this bug will become mostly moot -- but before closing it would be nice if someone familiar with the CUPS docs could confirm that the dimensions in custom page sizes are supposed to default to points when no units are given.
Then when I send the patch to Brother, I can reference this bug and they will have some incentive to patch their script.
It sounds like it would be helpful if a regression test for printer paper selection could be added to your test suite -- maybe something to run through all the paper sizes and verify that each size makes it to the CUPS layer?
Thanks for your work!
Bill
Assignee | ||
Comment 14•4 years ago
|
||
(In reply to Emilio Cobos Álvarez (:emilio) from comment #12)
https://treeherder.mozilla.org/#/jobs?repo=try&revision=1590390fe40771fdde6a5b6233a22c3444631769 should have a build in about an hour or so (click on the "B", then go to the "Artifacts" tab, then you can download a tarball with a Firefox binary). Could you check that build works for you?
Aand... the build from automation failed of course. Seems I was wrong, I thought we required GTK 3.16 but we require 3.14, so I need to add a version check etc... Will be right back with another build.
(In reply to Bill from comment #13)
It sounds like it would be helpful if a regression test for printer paper selection could be added to your test suite -- maybe something to run through all the paper sizes and verify that each size makes it to the CUPS layer?
Yeah, unfortunately I can't think of an easy way of end-to-end test this... In this case the bug is on GTK, which means that it's worse and I can't even unit test this really, meh :(
Assignee | ||
Comment 15•4 years ago
|
||
Reporter | ||
Comment 16•4 years ago
|
||
Hi Emilio,
I just tried your new build and printed a page .. worked fine, and the CUPS error_log has this:
D [19/Feb/2021:20:08:48 -0500] [Job 862] argv[0]="BrGenML1"
D [19/Feb/2021:20:08:48 -0500] [Job 862] argv[1]="862"
D [19/Feb/2021:20:08:48 -0500] [Job 862] argv[2]="bill"
D [19/Feb/2021:20:08:48 -0500] [Job 862] argv[3]="Important News"
D [19/Feb/2021:20:08:48 -0500] [Job 862] argv[4]="1"
D [19/Feb/2021:20:08:48 -0500] [Job 862] argv[5]="media=na_letter_8.5x11in Collate job-uuid=urn:uuid:ec09b97c-78e2-3b3e-635b-9b944319e458 job-originating-host-name=localhost date-time-at-creation= date-time-at-processing= time-at-creation=1613783328 time-at-processing=1613783328 PageSize=Letter"
So, looks good! With no custom page size it will definitely avoid the bug in the cupswrapper ..
Bill
Comment 17•4 years ago
|
||
Pushed by ealvarez@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/ef18a39a5f21 Prefer finding by ipp name when canonicalizing paper size in gtk. r=AlaskanEmily
Comment 18•4 years ago
|
||
bugherder |
Reporter | ||
Comment 19•4 years ago
|
||
I sent my cupswrapper patch to Brother via their customer support channel, so hopefully it will get updated at some point. If anyone with an MFC7360N printer installed as BrGenML1 needs to fix it now, this patch should work:
Comment hidden (duplicate) |
Updated•4 years ago
|
Comment 21•4 years ago
|
||
The patch landed in nightly and beta is affected.
:emilio, is this bug important enough to require an uplift?
If not please set status_beta
to wontfix
.
For more information, please visit auto_nag documentation.
Assignee | ||
Comment 22•4 years ago
|
||
Comment on attachment 9204326 [details]
Bug 1691798 - Prefer finding by ipp name when canonicalizing paper size in gtk. r=AlaskanEmily,jfkthame
Beta/Release Uplift Approval Request
- User impact if declined: Some printers will not work on Linux.
- Is this code covered by automated tests?: No
- Has the fix been verified in Nightly?: Yes
- Needs manual test from QE?: No
- If yes, steps to reproduce: (Needs specific hardware, but see comment 0)
- List of other uplifts needed: none
- Risk to taking this patch: Low
- Why is the change risky/not risky? (and alternatives if risky): I'd say it's a relatively low-risk change. We try a bit harder to find a paper that GTK understands.
- String changes made/needed: none
Comment 23•4 years ago
|
||
Comment on attachment 9204326 [details]
Bug 1691798 - Prefer finding by ipp name when canonicalizing paper size in gtk. r=AlaskanEmily,jfkthame
Approved for 87.0b3. Would be great if the reporter can verify that this is fixed for them after it ships to the Beta channel tomorrow.
Comment 24•4 years ago
|
||
bugherder uplift |
Reporter | ||
Comment 25•4 years ago
|
||
I downloaded Firefox 87.0b3 and tested by printing three pages with different page sizes. The pages printed as expected and a check of the CUPS error log showed that the page sizes matched the requested sizes (Letter, A4, and A5):
D [26/Feb/2021:07:56:51 -0500] [Job 872] argv[3]="Firefox"
D [26/Feb/2021:07:56:51 -0500] [Job 872] argv[4]="1"
D [26/Feb/2021:07:56:51 -0500] [Job 872] argv[5]="media=na_letter_8.5x11in Collate Duplex=None job-uuid=urn:uuid:00d32aec-918c-34c1-4de7-6bdd9b793d72 job-originating-host-name=localhost date-time-at-creation= date-time-at-processing= time-at-creation=1614344211 time-at-processing=1614344211 PageSize=Letter"
D [26/Feb/2021:07:58:58 -0500] [Job 873] argv[3]="Firefox"
D [26/Feb/2021:07:58:58 -0500] [Job 873] argv[4]="1"
D [26/Feb/2021:07:58:58 -0500] [Job 873] argv[5]="media=iso_a4_210x297mm Collate Duplex=None job-uuid=urn:uuid:5673122e-a107-3c4d-6d6b-d157318c3ab6 job-originating-host-name=localhost date-time-at-creation= date-time-at-processing= time-at-creation=1614344338 time-at-processing=1614344338 PageSize=A4"
D [26/Feb/2021:08:00:54 -0500] [Job 874] argv[3]="Firefox"
D [26/Feb/2021:08:00:54 -0500] [Job 874] argv[4]="1"
D [26/Feb/2021:08:00:54 -0500] [Job 874] argv[5]="media=iso_a5_148x210mm Collate Duplex=None job-uuid=urn:uuid:03a5da63-49a9-3169-7277-24ec7397013c job-originating-host-name=localhost date-time-at-creation= date-time-at-processing= time-at-creation=1614344454 time-at-processing=1614344454 PageSize=A5"
Previously all page sizes had been mapped to a custom size, so the bug has been fixed in 87.0b3.
Thanks for the quick resolution of this problem!
Comment 26•4 years ago
|
||
Yesterday, my system got updated to 86.0 and then suddenly I couldn't print again, also now I were looking at the new FF print interface.
85.0.1 worked, 86.0 does not, that 87.0b.3 works is nice - but don't guys think that you should send out a patch to solve it now, instead of people having to wait for 87 which comes out on march 23?
And that finding the cause of this would be a good idea, so that it doesn't happen again and again, and so on in every second release - it started for me with 75.
For now: I figured out a work around for those who don't want an developer beta version installed, and will wait for 87 to come out march 23:
click on "Print..." Ignore the new print interface of FF and click on "Print using system dialog..." change the papersize to first A5 and then back to A4 the printer now prints as it should.
Again: This do NOT work with Firefox new build-in printer settings.
Jan
I'm have been a loyal user since Netscape, at that time I worked support for many companies that bought IBM, Compaq, HP and Packard Bell computers and various printers, for their offices and Home PC users.
I quit Windows for good about 6 years ago, and went on different distro of Linux, until i found the one I'm using for the past 6 years as my permanent driver, when you guys make changes like this and break things, it were hard enough in windows(which most developers still seem prioritize over linux), and makes it even harder in linux. Maybe don't try to be the first to come out with new stuff, but test it first and then send out a stable solution. Thank you for all the years past:)
Reporter | ||
Comment 27•4 years ago
|
||
Hi Jan,
If you're seeing on-again, off-again printing with recent Firefox builds, the problem is likely different from the custom pagesize issue here. To track it down further, I'd suggest turning on CUPS debugging by setting Loglevel to debug in the CUPS config file. Then try printing a page using a failing Firefox build, and inspect the CUPS error log for signs of problems with that print job.
If nothing obvious pops out, try printing the same page with the same settings from a Firefox build that works, and look for differences in the CUPS error log between the two jobs. If you can pinpoint the cause in the error logs, there's a much better chance that the problem can be fixed, either in Firefox or by tweaking your printer driver setup.
On my system I keep CUPS debugging turned on (with a 1M file limit) so that it's easier to track down printer problems.
Assignee | ||
Comment 28•4 years ago
|
||
Yeah, this change isn't in Firefox 86. If you can reproduce on Beta 87 or Nightly, please file a new bug and ni? me and I'd be happy to poke at it. Thanks!
Comment 29•4 years ago
|
||
Well, I disagree - I'm not an expert in this, but if I change page size then print works, so must have something to do with the bug, right?
click on "Print..." Ignore the new print interface of FF and click on "Print using system dialog..." change the papersize to first A5 and then back to A4 the printer now prints as it should.
I have no idea on how to turn on debug in loglevel or where to find the CUPS config file, and even how to see the log.
I quit windows because I had enough of MS's BS(after working with their products as supporter and IT consultant for over 35 years), and tried many different kind of OS's before landing on the one I use now, which a slightly modified Xubuntu 16.04 and when 20.04 is finished I will go on that one - might take a while since the author is busy with something else:)
In the meantime it would be nice to be able to print from FF.
Though I may not know how to do something, doesn't mean I'm not willing to learn:)
Jan
Assignee | ||
Comment 30•4 years ago
|
||
Please do file a separate bug if using a nightly build doesn't work, and we can debug it there. We can mark the bug as "See also" or such to indicate that this bug might be related.
Reporter | ||
Comment 31•4 years ago
|
||
Hi Jan,
If you enter localhost:631/admin as the URL in your browser, it should take you to the CUPS admin page. On the right side there are buttons to edit the config file and to view the error log. Once debugging is turned on, if a print job fails there will likely be some messages in the error log as to the the cause of the failure.
Since you can make the print jobs succeed or fail by fiddling with paper sizes, you should be able to capture some specific error messages so the bug can be tracked and fixed.
Good luck with the bug hunting!
Bill
Comment 32•4 years ago
|
||
Hi Bill, Content of the config file - I can't see where to turn on logging:
LogLevel debug
PageLogFormat
MaxLogSize 0
Allow remote access
Port 631
Listen /var/run/cups/cups.sock
Browsing On
BrowseLocalProtocols dnssd
DefaultAuthType Basic
WebInterface Yes
<Location />
Allow remote access...
Order allow,deny
Allow all
</Location>
<Location /admin>
</Location>
<Location /admin/conf>
AuthType Default
Require user @SYSTEM
</Location>
<Location /admin/log>
AuthType Default
Require user @SYSTEM
Order allow,deny
Order allow,deny
Allow all
Order allow,deny
Allow all
</Location>
<Policy default>
JobPrivateAccess default
JobPrivateValues default
SubscriptionPrivateAccess default
SubscriptionPrivateValues default
<Limit Create-Job Print-Job Print-URI Validate-Job>
Order deny,allow
</Limit>
<Limit Send-Document Send-URI Hold-Job Release-Job Restart-Job Purge-Jobs Set-Job-Attributes Create-Job-Subscription Renew-Subscription Cancel-Subscription Get-Notifications Reprocess-Job Cancel-Current-Job Suspend-Current-Job Resume-Job Cancel-My-Jobs Close-Job CUPS-Move-Job CUPS-Get-Document>
Require user @OWNER @SYSTEM
Order deny,allow
</Limit>
<Limit CUPS-Add-Modify-Printer CUPS-Delete-Printer CUPS-Add-Modify-Class CUPS-Delete-Class CUPS-Set-Default CUPS-Get-Devices>
AuthType Default
Require user @SYSTEM
Order deny,allow
</Limit>
<Limit Pause-Printer Resume-Printer Enable-Printer Disable-Printer Pause-Printer-After-Current-Job Hold-New-Jobs Release-Held-New-Jobs Deactivate-Printer Activate-Printer Restart-Printer Shutdown-Printer Startup-Printer Promote-Job Schedule-Job-After Cancel-Jobs CUPS-Accept-Jobs CUPS-Reject-Jobs>
AuthType Default
Require user @SYSTEM
Order deny,allow
</Limit>
<Limit CUPS-Authenticate-Job>
Require user @OWNER @SYSTEM
Order deny,allow
</Limit>
<Limit All>
Order deny,allow
</Limit>
</Policy>
<Policy authenticated>
JobPrivateAccess default
JobPrivateValues default
SubscriptionPrivateAccess default
SubscriptionPrivateValues default
<Limit Create-Job Print-Job Print-URI Validate-Job>
AuthType Default
Order deny,allow
</Limit>
<Limit Send-Document Send-URI Hold-Job Release-Job Restart-Job Purge-Jobs Set-Job-Attributes Create-Job-Subscription Renew-Subscription Cancel-Subscription Get-Notifications Reprocess-Job Cancel-Current-Job Suspend-Current-Job Resume-Job Cancel-My-Jobs Close-Job CUPS-Move-Job CUPS-Get-Document>
AuthType Default
Require user @OWNER @SYSTEM
Order deny,allow
</Limit>
<Limit CUPS-Add-Modify-Printer CUPS-Delete-Printer CUPS-Add-Modify-Class CUPS-Delete-Class CUPS-Set-Default>
AuthType Default
Require user @SYSTEM
Order deny,allow
</Limit>
<Limit Pause-Printer Resume-Printer Enable-Printer Disable-Printer Pause-Printer-After-Current-Job Hold-New-Jobs Release-Held-New-Jobs Deactivate-Printer Activate-Printer Restart-Printer Shutdown-Printer Startup-Printer Promote-Job Schedule-Job-After Cancel-Jobs CUPS-Accept-Jobs CUPS-Reject-Jobs>
AuthType Default
Require user @SYSTEM
Order deny,allow
</Limit>
<Limit Cancel-Job CUPS-Authenticate-Job>
AuthType Default
Require user @OWNER @SYSTEM
Order deny,allow
</Limit>
<Limit All>
Order deny,allow
</Limit>
</Policy>
Comment 33•4 years ago
|
||
In the admin page this one do have a checkmark, is that what you meant?
Save debugging information for troubleshooting
Reporter | ||
Comment 34•4 years ago
|
||
Hi Jan,
The first line LogLevel debug is what you need -- debugging is already turned on. If you check the Error log now after a failing job, there should be some good clues as to what went wrong. The error log is usually pretty verbose though, so it may take a while to locate the messages for a particular job.
The checkmark may be what turned on the debugging, but in any event it's on.
Bill
Comment 35•4 years ago
|
||
Printing via FF own new print option, error log attached.
Comment 36•4 years ago
|
||
That didn't work, I got an error when trying to attach text.
i have uploaded everything to my dropbox, screenshot and log files here https://www.dropbox.com/sh/4sl94pledbodkvy/AACv9zIt3OrUFJEjikwfNXjba?dl=0
Reporter | ||
Comment 37•4 years ago
|
||
Hi Jan,
The CUPS error log is very noisy, so you'll need to dig into it to find the relevant problem. The screeenshot showed that Job 233 failed, and if you search the error log for 233 you find this:
800] cupsdMarkDirty(---J-)
D [18/Mar/2021:10:51:32 +0800] cupsdSetBusyState: newbusy="Printing jobs and dirty files", busy="Printing jobs and dirty files"
D [18/Mar/2021:10:51:32 +0800] [Job 233] PID 12182 (/usr/lib/cups/filter/rastertocanonij) stopped with status 255 (Unknown error 155)
D [18/Mar/2021:10:51:32 +0800] [Job 233] PID 12180 (/usr/lib/cups/filter/pdftopdf) exited with no errors.
D [18/Mar/2021:10:51:32 +0800] [Job 233] Color Manager: Calibration Mode/Off
So the problem apparently occurred in the filter rastertocanonij. The next step would be to see if that filter left around some tmp files, or if it has a debugging mode that can be turned on. There may be some additional messages there that would help diagnose the problem further.
Anyway, you're much closer to finding the problem :-)
Comment 38•3 years ago
|
||
Hi Bill, after updating to FF 87.0 the problem is gone, just hope it will not re-occur.
Thank you for all you patience helping me look into this, at last it would seem it indeed were a FF problem, as I have not done anything else than updating FF.
with kind regards and if you are ever finding yourself in Puerto Galera, Oriental Mindoro, 5203 Philippines, then look me up. I live above and on the back of Iglesia ni christo. And I buy you a steak:)
Jan
Description
•