 QUESTION: What's your opinion on MS tightening the license-policy on Vista? Will this help promote Ubuntu, since a lot of people dont't want MS looking over their shoulder every three weeks?
[07:17] <sabdfl> stefg: yes, if MS really enforces their licensing of Vista, and makes it impossible to run it without paying for it, this will hugely drive the adoption of desktop linux
[07:18] <Seveas> I have one of my own: would you return to space if you had the chance?
[07:18] <sabdfl> Seveas: well, technically, i have the chance every April and October when a Soyuz goes to the ISS :-)
[07:18] <Seveas> hehe
[07:18] <Seveas> ok, next:
 QUESTION: How about fluendo's solution to mp3 codecs. They purchased the rights and then made a plugin that can be legally used in lgpl players such as banshee
[07:18] <sabdfl> i would love to go up again, it's a huge privilege
[07:18] <sabdfl> but i feel i want to earn that privilege by doing something awesome on the ground
[07:19] <sabdfl> something noone else can pull off
[07:19] <sabdfl> and that's ubuntu
[07:19] <sabdfl> also
[07:19] <sabdfl> i am waiting for the possibilities in space to open up
[07:19] <sabdfl> for example, a new craft, or the ability to push a Soyuz further or faster than anyone else :-)
[07:19] <sabdfl> woodwizzle: it's still binary-only, AFAIK, with redistribution issues
[07:20] <sabdfl> so we won't ship that
[07:20] <sabdfl> if i'm wrong, someone please holler!
[07:20] <Seveas> sabdfl: afaik it's open source
[07:20] <Seveas> and they offer free patent licenses to redistributors
[07:20] <Seveas> (free as in gratis)
[07:20] <sabdfl> however, we WILL make it very easy for you to activate MP3 support if you can legally do so
[07:21] <sabdfl> for example, if you have a patent licence, or for research purposes, or if there are no relevant patents in your jurisdiction
[07:21] <sabdfl> Seveas: i'm intrigued, happy to hear more on this
[07:21] <Seveas> sabdfl, after the session ;)
[07:22] <Seveas> Something asked a few times: Will PPC support be discontinued soon?
[07:22] <sabdfl> We will make a final decision on PPC for Feisty by the end of next week
[07:22] <sabdfl> if there is sufficient community contribution on this, then the community port can be just as good as a Canonical-supported one
[07:23] <sabdfl> we would keep the builds in place, but not block the release if things failed to build
[07:23] <sabdfl> so if people step up to unblock issues when they occur, then PPC would be on the same footing as it currently is
[07:23] <Seveas> sabdfl, will "but ps3 is ppc" be a valid argument? (asked a few times as well)
[07:24] <sabdfl> the extra architecture costs us a lot in terms of testing bandwidth at release time, and figuring out issues like how to deal with the live CD are compicated
[07:24] <sabdfl> if SONY fund Ubuntu-on-PS3 then I guarantee it will happen :-)
[07:24] <sabdfl> if not, then its hard to rationalise it on either philanthropic or commercial grounds
 QUESTION: Do you think that the free software community could be an example for other areas of human interaction, to show the benefits of not being primarily money motivated, but cause motivated?
[07:25] <sabdfl> Sanne: yes
[07:25] <sabdfl> it's not so much money-vs-cause
[07:25] <sabdfl> as collaboration and participation
[07:26] <sabdfl> i think this meme will spread to every industry
[07:26] <sabdfl> commerce will of course continue
[07:26] <sabdfl> salaries get paid
[07:26] <sabdfl> contracts get issued
[07:26] <sabdfl> but people will find a way to express their personal interests as community-owned work
[07:26] <sabdfl> like wikipedia
[07:27] <Seveas> A few from the "How can we" department that relate to the same issue: How can we coax GPU companies to open up? How can we attract game developers and users?
[07:27] <sabdfl> first we have to make them care about the linux platform
[07:27] <sabdfl> that means - get tens, hundreds of millions of users
[07:28] <sabdfl> without that, they have no incentive even to spend the money to THINK about this question
[07:28] <sabdfl> second, we have to show them that they will benefit by being open
[07:28] <sabdfl> that their cost of production will be reduced
[07:28] <sabdfl> and their quality will go up
[07:28] <sabdfl> i would like to hear from Intel on their experiences, for example
[07:28] <sabdfl> third, we have to show them that their competitive position will improve
[07:29] <sabdfl> so, if we push Nvidia users to ATI, and there are lots of users who make buying decisions based on that, then Nvidia will notice and act accordingly
[07:29] <sabdfl> we need to gather leverage, and then use it
 <gip> Can you ask: QUESTION: How many people is actively using Ubuntu today? How is the market share increment now?
[07:30] <sabdfl> I think 4-8 million use Ubuntu directly
[07:30] <sabdfl> probably double that if you factor in derivatives too
 QUESTION What about the mysterious "landscape-client", Mark?
[07:31] <sabdfl> gummibaerchen: it's a GPL piece of code that will allow you to get web-based monitoring of your machine in future, through a service from Canonical
[07:32] <sabdfl> we will encourage other ISV's to extent that GPL client to monitor other aspects of the system, for example, database performance
[07:32] <sabdfl> to make it easy to manage large numbers of Ubuntu machines
 QUESTION: What are the chances of seing some Ubuntu-branded online services. For instance, a calendar that shows your appointments on every (internet connected) Ubuntu computer you log into, or perhaps some Ubuntu-branded email/webmail?
[07:33] <sabdfl> tom56: damn, that's a good idea!
[07:33] <sabdfl> i'd like to provide a syncing service, and we do have ubuntu.net so...
[07:33] <Seveas> Ubuntu Live!
 QUESTION: With Java now under the GPL will Sun's JDK/JRE be included in Fiesty?  Also, do you anticipate some of Sun's Java Desktop being included in future releases of Ubuntu?
[07:34] <sabdfl> ryeyawn: yes, absolutely, now that SUN has taken that step its just a question of time before Java makes its way to main
[07:34] <sabdfl> i think the core pieces might be there now
[07:34] <sabdfl> and it's great that SUN engineers are working to make this possible
[07:34] <sabdfl> there are still some licence blockers
[07:34] <Seveas> (we're missing a few core pieces that aren't free yet)
[07:34] <sabdfl> but sun is committed (I believe) to clearing those as fast as possible
[07:34] <sabdfl> we won't move pieces to main till they are free
[07:35] <sabdfl> if you want to help there, i can put you in touch with the right people
[07:35] <sabdfl> starting with tmarble :-)
[07:35] <Seveas> there were quite a few questions about including ndiswrapper by default, i think. or, perhaps the broader question -- How to deal with the problem of people with Internet connections that cannot be used by Ubuntu by default, when installing the software to enable them would involve having a working Internet connection in the first place?
[07:36] <sabdfl> ndiswrapper-by-default is not something i want to wrap my brain around just now
[07:36] <Seveas> heh
[07:36] <sabdfl> it's possible
[07:36] <gnomefreak> heh
[07:36] <sabdfl> and it would be legal, AFAICS
[07:36] <sabdfl> if it were proven stable, then it might be a useful last-ditch plan
[07:36] <sabdfl> for winmodems etc
[07:37] <sabdfl> tell me about the internet connection issue?
[07:37] <sabdfl> is this PPPOE?
[07:37] <gnomefreak> sabdfl: wireless
[07:37] <Seveas> More like "not having one"
[07:37] <sabdfl> i would like to see PPPOE solved, if anyone else would like to help then please get in touch with me
[07:37] <Seveas> it's not easy to install packages/upgrade UBuntu without one
[07:37] <gnomefreak> the users that need it have no conection to instll it
[07:38] <sabdfl> not having one because there are no linux drivers, even non-free ones?
[07:38] <Seveas> in general
[07:38] <Seveas> not being connected
[07:38] <sabdfl> i believe cjwatson is working on the ability to add drivers at install time
[07:38] <sabdfl> so folks could use a USB drive to add a driver they downloaded using <cough> some other OS</cough>
 QUESTION: What needs to be done to push FOSS software in UK schools today? I have come through schools that have used almost exclusively Microsoft software and other propriatery software solutions, for almost everything. It could save huge amounts of money on licensing etc. and the Vista upgrade looks a scary one for most education establishments.
[07:39] <gnomefreak> sabdfl: thats what we have them do but im hearing its on alternate cd
[07:39] <sabdfl> gnomefreak: i thought it was on Live CD, but please check with cjwatson (or Colin, please chip in if you're watching)
[07:40] <sabdfl> ToonArmy: we should not push the "save huge amounts of money" button
[07:40] <sabdfl> instead, we should ask how the govt plans to provide for:
[07:40] <sabdfl>  - musician pupils
[07:40] <gnomefreak> if he dont answer i will get up with him in next 24 hours to find out
[07:40] <sabdfl>  - statistics pupils
[07:40] <sabdfl>  - physics pupils
[07:40] <sabdfl>  - language pupils
[07:40] <sabdfl>  - comp sci pupils
[07:40] <sabdfl> ...
[07:40] <sabdfl> the point is that, with free software, we have a HUGE variety of tools for teaching and learning
[07:41] <sabdfl> really, really wide variety
[07:41] <sabdfl> the equivalent in proprietary software is (a) not possible to find and (b) enormously expensive
[07:41] <sabdfl> Windows+Office is not "it"
[07:41] <sabdfl> we have to broaden people's perception about what computers can achieve in learning
[07:41] <sabdfl> and show that free software is the only way, really, to deliver all of that
 QUESTION: Best and worst moment since Ubuntu project started?
[07:42] <sabdfl> Bourlotieris: dapper release, and the x update mistake
 QUESTION: Can we learn something from Apple in terms of getting Windows users to 'switch'? What are your views on OS X?
[07:43] <sabdfl> sadiq: i think we can learn a lot from apple in terms of "what users want"
[07:43] <sabdfl> however, we don't want to go down their proprietary road of AAC-hell
[07:44] <sabdfl> OS X is a testament to what is possible with end user experience on UNIX
[07:44] <sabdfl> so lets show that it can be even better
[07:44] <sabdfl> and even more open
 QUESTION: Mark, Ubuntu Server, How about comparing/ competing with red-hat clusters?
[07:45] <sabdfl> amachu: interesting
[07:45] <sabdfl> there are a lot of scientists that build their own HPC platforms
[07:45] <sabdfl> it would be nice to get enough of them together to work on a REALLY-SCALABLE-BUNTU
[07:45] <sabdfl> HA-clusters are slightly different
[07:45] <sabdfl> that is more enterprise-ish
[07:46] <sabdfl> chat with fabbione, i think he wants to see Ubuntu HA clustering rock
[07:46] <sabdfl> Seveas?
[07:46] <Seveas> (as in: Ubuntu rocks on the hpc cluster I built ;))
[07:46] <sabdfl> rock star :-)
 QUESTION: Let me rephrase my question: If the Nouveau drivers manage to provide working 3D on nvidia cards, would a certain decrease in performance be acceptable to avoid using the nonfree driver by default?
[07:46] <sabdfl> jonasj: yes
[07:46] <sabdfl> at least, IMO
 QUESTION: sabdfl, a few municipal administrations in europe are in the process of implementing linux for their infrastructure. How could ubuntu take part in that?
[07:48] <sabdfl> guglielf: we could provide a forum for the specific items they want to collaborate with the community on, and of course they could contract to get commercial support etc with Canonical. so hopefully ubuntu should represent the best of both worlds to them.
[07:48] <sabdfl> if you know folks involved, please encourage them to look more closely at ubuntu
 QUESTION: Debian call themselves 'GNU/Linux'. Why not you guys?
[07:49] <sabdfl> arjun: we do give appropriate credit to the GNU community
[07:49] <sabdfl> both personally (i always make a point of this in presentations and speeches) and on the website etc
[07:49] <sabdfl> i'm not going to get drawn into calling it "GNU/Linux for Human Beings"
[07:49] <sabdfl> that's just... silly, and I don't mind you quoting me on that
[07:50] <Amaranth> and then the first thing you have to explain to a new user is what a recursive acronym is :)
[07:50] <sabdfl> the FSF and Gnu project have breathed life into the free software movement
[07:50] <sabdfl> we should always credit them with that
[07:50] <sabdfl> but also, remember there's a huge amount that we depend on every day that comes from other parts of the free software community
[07:50] <sabdfl> look at the amazing work of the apache foundation
[07:51] <sabdfl> so to my mind its about giving credit where its due
[07:51] <sabdfl> debian, fsf, even the much-maligned OSI
[07:51] <sabdfl> apache, bsd, UNIX... we stand on the shoulders of giants
 QUESTIONS: How satisfied are you with the LoCo Teams ? Few words about them?
[07:52] <sabdfl> ok, my fingers are letting me know that i'm talking too much
[07:52] <Seveas> and the next session starts shortly
[07:52] <sabdfl> LoCo teams are an AWESOME part of our community
[07:52] <Seveas> I think we should make this the last question, so we have time for the "thank you" rain that will follow
[07:52] <sabdfl> often when I visit countries and run into the LoCo teams i'm very humbled by the energy and advocacy they bring
[07:53] <sabdfl> its an amazing thing, to interact with people face to face and help them learn about this free software thing
[07:53] <sabdfl> i never read about linux in a magazine
[07:53] <sabdfl> actually, thats not true
[07:53] <sabdfl> i read about it a LOT
[07:53] <sabdfl> and online
[07:53] <sabdfl> i just never did anything about it
[07:53] <sabdfl> till someone GAVE me a stack of slackware floppies
[07:53] <sabdfl> that's the power of real-world advocacy
[07:53] <sabdfl> i'd like to figure out how we help the LoCo teams get more organised
[07:54] <sabdfl> give them better materials
[07:54] <sabdfl> help them work with the media
[07:54] <sabdfl> but in general, those that are active are fantastic
[07:54] <Seveas> sabdfl, how many more questions do you want?
[07:54] <sabdfl> lat two
[07:54] <sabdfl> last two
[07:54] <Seveas> ok
 QUESTION: what about a some ubuntu-commercials like the apple "switch" ones, or some video-contest like the firefox-flicks? it would be nice to see some Ubuntu users in a video. it's time to show, that linux-users are not only "geeks" and "nerds" anymore. :-)
[07:55] <sabdfl> suzan: cool idea! why not talk to the ubuntu-studio guys about that?
 QUESTION: Sabdfl, why are you taking all the trouble, like competing MS, running a distro and making it big... Wouldn't it be nicer to spent the whole day poolside with a cool drink ?
[07:56] <sabdfl> stefg: well, some days....
[07:56] <sabdfl> thing is, it would be boring to do nothing. i've had my time off between projects, and i just get itchy
[07:56] <sabdfl> i start thinking about how the world is changing
[07:57] <sabdfl> and how to make it GO FASTER
[07:57] <sabdfl> and this is the best thing for me to be doing right now
[07:57] <sabdfl> also
[07:57] <sabdfl> well, that's enough
[07:57] <sabdfl> thanks guys
[07:57] <sabdfl> thank you for the contribution everyone makes to this project
[07:57] <sabdfl> makes me very proud to be a part of it
[07:57] <Seveas> Thank YOU for taking the time and effort to answer all the questions
[07:58] <sabdfl> seveas, thanks for playing cop, as always
[07:58] <pitti> thanks sabdfl
[07:58] <ailean> thanks for staying mark - please do improve the help for people who want to help. i need guidance and find it difficult to get it. I'll make sure I send a note too :)
[07:58] <rulus> Wooohhoooo thanks Mark! Mark's cool!
[07:58] <polvi> thanks!! :)
[07:58] <topyli> thanks sabdfl!
[07:58] <_jmk_> kudoz to sabdfl, great project
[07:58] <LjL> Thank you sabdfl
[07:58] <sven-tek> encrypt your hardisc!
[07:58] <Webspot> thanks
[07:58] <noela> it's been educative and amusing, sabdfl , muchas gracias, thanks for everything!
[07:58] <ToonArmy> Thanks!!
[07:58] <sabdfl> so, who's up next?
[07:58] <Jonathon> Thanks for your time, sabdfl
[07:58] <mogwai> Cheers - keep up the good work!
[07:58] <lotusleaf> Bruce Dickinson is god
[07:58] <somerville32> Thanks!
[07:58] <brent_cool> THANK YOU!
[07:58] <maccabeus> thanks marc!!
[07:58] <Sanne> Thank you for a very enjoyable and informative Ask Mark session :)
[07:58] <suzan> thanks a lot!
[07:58] <woodwizzle> w0000000t!
[07:58] <NickH_> do it
[07:58] <pitti> sabdfl: I am :)
[07:58] <rdp> Thank you!
[07:58] <Slike> thx!
[07:58] <Chris7mas> thank you
[07:58] <ktogias> thanks sabdfl !!!
[07:58] <brent_cool> FTW!
[07:58] <stgraber> thx
[07:58] <wedderburn> cheers
[07:58] <Amaranth> YIKES
[07:58] <suzan> and, ubuntu need more women! ;-)
[07:58] <Metro> Thanks Mark
[07:58] <yipe> YAY!
[07:58] <arjun> thanks!
[07:58] <_MMA_> METAL!!! \m/
[07:58] <sabdfl> rock on, pitti
[07:58] <jonasj> thank you very much for the last two hours, and for ubuntu
[07:58] <Bourlotieris> Thank YOU Mark
[07:58] <sire1> Thankiu for interesting talk :0
[07:58] <Vhata> kram sknaht
[07:58] <LjL> Amaranth: well what did you expect
[07:58] <thefisist> really interesting. thanks mark
[07:58] <sire1> :)
[07:58] <nemphis> thx mark
[07:58] <torkiano> plas,plas,plas
[07:58] <gummibaerchen> thx+
[07:58] <exo-griffith> thank you, Mark.
[07:58] <ktogias> clap clap clap
[07:58] <ryeyawn> Thanks for everything Mark.
[07:58] <Bert> thanks
[07:59] <gummibaerchen> was great
[07:59] <reaton> thanks mark
[07:59] <ailean> sabdfl, must feel like a rock star
[07:59] <samgee> thx a bunch
[07:59] <corstar> Thanks to the ubuntu team for making all of this possible. VIVA UBUNTU
[07:59] <somerville32> Woot! :D
[07:59] <yipe> thanks for making linux good enough for my mom to switch!
[07:59] <johnnybuoy> I can write whatever
[07:59] <Amaranth> LjL: Actually I expected the volume to make me lag. :)
[07:59] <johnnybuoy> YAY
[07:59] <PhilStone> thanks mark
[07:59] <johnnybuoy> woot
[07:59] <ktogias> VIVA UBUNTU!
[07:59] <tim_> Thank You Very Much
[07:59] <LjL> Amaranth: well, it *is* making me lag, but then i'm on konversation
[07:59] <Lesley> Tx! have a greeeaaaat evening!
[07:59] <_MMA_> http://ubuntustudio.org and #ubuntustudio on Freenode
[07:59] <lotusleaf> sabdfl for president 2008
[07:59] <somerville32> Woo!
[07:59] <Morph> For anyone in or planning on being in Southern California in february 2007, the Southern California Linux Expo will have an Ubuntu presence..http://www.socallinuxexpo.org
[07:59] <Amaranth> Admiral_Chicago: me too
[07:59] <topyli> hehe
[07:59] <brent_cool> i've got my mom, dad, and girlfriend using ubuntu now, THANKYOU EVERYONE!
[07:59] <yipe> yay sabdfl
[07:59] <lorenzo> sabdfl: Thanks very much for Ubuntu.  Keep up the good work.
[07:59] <Admiral_Chicago> Amaranth: sweet
[07:59] <zch> Vielen Dank
[07:59] <Seveas> Next up is pitti
[07:59] <ogra> thanks sabdfl
[07:59] <tm|ubuntu> Morph: yay
[08:00] <lotusleaf> how easy is it to use a hookah in space?
[08:00] <topyli> cool brent_cool !
[08:00] <mogwai> kudos to you and the community
[08:00] <Seveas> Can we please return to "chatter in #ubuntu-classroom-chat" mode
[08:00] <exo-griffith> brent_cool, that's cool. Good job!
[08:00] <jorgp> thanks sabdfl,
[08:00] <brent_cool> i know!
[08:00] <corstar> Mark said there are "4-8 million Ubuntu users". Man, that ROCKS!!
[08:00] <pitti> WELCOME TO MY CLASS
[08:00] <Panzerboy_> hey pitti
[08:00] <Seveas> hi pitti!
[08:01] <radix> hooray pitti :)
[08:01] <Bert> test
[08:01] <Seveas> failed
[08:01] <DreamThief> hi pitti
[08:01] <pitti> I have a rather technical presentation now, for everyone who wants to modify anything in Ubuntu
[08:01] <highvoltage> win 13
[08:01] <rulus> can we please set mode to +M
[08:01] <cga> Seveas, will sabdfl have another session later?
[08:01] <pitti> just as a quick overview, who is here to learn about patching?
[08:01] <brent_cool> me
[08:01] <_jmk_> check
[08:01] <jorgp> me me
[08:01] <ktogias> me
[08:01] <amnesia> me
[08:01] <ssam> me
[08:01] <corstar> yep
[08:01] <acez> me
[08:01] <thekorn> me
[08:01] <rulus> me too
[08:01] <LinuxBA> yep
[08:01] <aeig> me
[08:01] <Amaranth> hahaha
[08:02] <Bert> me too
[08:02] <pitti> great!
[08:02] <mihakriket> me
[08:02] <Netfinity> me
[08:02] <romey> me
[08:02] <pitti> ok, time's limited, let's start
[08:02] <adrian3> me too
[08:02] <pitti> if anyone has any question, or I'm totally uncomprehensible (sorry, I'm German), please do not hesitate to interrupt and ask *immediately*
[08:02] <pitti> Also, don't bother trying to take notes, we'll sort that out at the end. You can fully concentrate on the discussion and examples.
[08:02] <zch> me too
[08:02] <pitti> Let's begin with a little bit of history:
[08:02] <Amaranth> Settle down guys, we need to let pitti teach us stuff. :)
[08:02] <pitti> == Why use separate patches ==
[08:02] <pitti> In earlier times, people just applied patches inline (i. e. directly in the source code tree). However, this makes it very hard to extract patches later to modify them, send them upstream, etc. Also this means that new upstream versions are a pain, since they generate a lot of rejections when applying the package diff.gz to them.
[08:02] <pitti> With split-out patches it is much easier to send them upstream, keep track of them, develop them, etc., since you always see which changes belong together.
[08:02] <pitti> The ideal state is an unmodified tarball from upstream, plus clean and separate patches, plus the packaging bits in debian/. That means that lsdiff <sourcepackage>.diff.gz only contains debian/.
[08:02] <pitti> The first attempts to split-out patches were pretty trivial: storing patches in debian/patches/, and adding some patch/patch -R snippets to debian/rules. This worked for small patches, but provided no tools for editing these patches, updating them for new upstream versions, etc.
[08:02] <pitti> Thus several standard patch systems were created which are easy to deploy and provide tools for patch juggling and editing.
[08:03] <dieterd> german too
[08:03] <rulus> not so fast pls
[08:04] <pitti> What I would like to do now is to introduce the most common patch systems and show some hands-on demo how to add a new patch and how to edit one. For this, I will point at a source package from the current dapper archive, quickly explain the patch system, and show how to apply some (braindead) modifications to it. I recommend you to do the same steps in a terminal, so that you get a feeling for the process and can immediately ask questions.
[08:04] <pitti> everyone you fine with this approach?
[08:04] <pitti> erm, of course I mean 'from the edgy archive', not dapper
[08:04] <pschulz01> pitti: Is the package the same in edgy?
[08:04] <Seveas> pitti, please name the packages now so we can apt-get source them
[08:04] <pitti> yeah, I don't want it to be entirely theoretical :)
[08:05] <pitti> If you want to try the stuff yourself, please do the following commands (on edgy) as preparation:
[08:05] <pitti>   sudo apt-get install dpatch cdbs quilt patchutils
[08:05] <pitti>   apt-get source cron udev pmount gnome-volume-manager ed xterm
[08:05] <pitti>   wget http://people.ubuntu.com/~pitti/scripts/dsrc-new-patch
[08:05] <pitti>   chmod 755 dsrc-new-patch
[08:05] <pitti> I deliberately picked the smallest packages I could find
[08:05] <dieterd> discussion is to fast to read
[08:05] <pitti> dieterd: ok, I wait a bit for catching up, please ping me if you guys are ready
[08:06] <amnesia> it's not him too fast, but the joiners/parters. channels should be invite only once lessons are started
[08:06] <pitti> yeah, those messages are pretty disturbing
[08:06] <Seveas> amnesia, set your chat client to ignore them
[08:06] <pitti> Seveas: quick how-to for xchat?
[08:07] <amnesia> what's easier, everyone sets their clients or just one +i
[08:07] <Snarius> pitti, rclick on channel tan
[08:07] <H3g3m0n> Settings>Advanced>Text Events and delete the Join Part entries (might want to save the list for easy undo)
[08:07] <Snarius> *tab
[08:07] <highvoltage> /ignore #ubuntu-classroom JOINS QUITS
[08:07] <pitti> Snarius: ah, right
[08:08] <dieterd> Patching Packages - Martin Pitt
[08:08] <Amaranth> amnesia: We want people to be able to come in later
[08:08] <pitti> ok, everyone set with the intro and getting source packages?
[08:08] <Amaranth> amnesia: Schools don't lock their doors on you if you're 5 minutes late
[08:08] <rulus> mine does :(
[08:08] <amnesia> Amaranth: they do where I live
[08:08] <noela> mine did, Amaranth
[08:08] <noela> lol
[08:08] <highvoltage> here too
[08:08] <pitti> OT
[08:08] <jonh_wendell> pitti, still apt-get sourcing...
[08:08] <Amaranth> Anyway...
[08:08] <Chastell> /ignore #ubuntu-classroom JOINS QUITS
[08:08] <amnesia> ok let's drop it and get on with packaging ;)
[08:08] <noela> (but you're right)
[08:09] <pitti> nevermind, for the first bit we don't yet need the packages
[08:09] <ktogias> ready
[08:09] <pitti> == cron: inline patches ==
[08:09] <pitti> No patch system at all, nothing much to say about this.  You directly edit the files in the source tree. This is convenient for a simple and quick change, but will bite back for new upstream versions (see above) and is inconvenient for submitting patches upstream, or reviewing for merges.
[08:09] <pitti> if you do 'lsdiff <package>.diff.gz' and you see changes which are not in debian/, then you probably have such a package
[08:09] <pitti> (some KDE packages have autoconf stuff directly in the diff.gz, but that is ok)
[08:09] <pitti> so, I think I do not need to say anything else about cron, unless someone has a question
[08:10] <dieterd> http://www.timeanddate.com/worldclock/fixedform.html?year=2006&month=11&day=27&hour=15&min=0&sec=0    ----  on my computer it was saying three o clock for ubuntu talk program
[08:10] <CyberKahn>  /ignore #ubuntu-classroom JOINS QUITS
[08:10] <pitti> ok, no question here
[08:10] <pitti> so, people, get a grip, now it gets heavy
[08:11] <pitti> == udev: separate patches, but no patch system ==
[08:11] <pitti> This case is the most complicated one since you have to do all the hard work manually. In order to make you understand what a patch system does, and to give you a fallback method that will *always* work with any patch system, I handle this first.
[08:11] <pitti> The good news is that you will seldomly be required to actually do this procedure, I'll come to this again.
[08:11] <pitti> The general approach is:
[08:11] <pitti> 1. copy the clean source tree to a temporary directory /tmp/old
[08:11] <pitti> 2. apply all patches up to the one you want to edit; if you want to create a new patch, apply all existing ones (this is necessary since in general patches depend on previous patches)
[08:11] <pitti> if you want, you can use debian/rules for this: remove the patches that come *after* the one you want to edit, and call 'debian/rules patch'. The actual name for the patch target varies, I have seen the following ones so far: patch setup apply-patches unpack patch-stamp. You have to look in debian/rules how it is called.
[08:11] <pitti> 3. copy the whole source tree again: cp -a /tmp/old /tmp/new
[08:11] <pitti> 4. go into /tmp/new, do your modifications
[08:11] <pitti> 5. go back into /tmp generate the patch with
[08:11] <pitti>   diff -Nurp old new > mypatchname.patch
[08:11] <pitti> and move the patch to .../debian/patches/mypatchname.patch
[08:11] <pitti> ^ that's the theory, example will follow shortly (hands-on training)
[08:12] <jonh_wendell> pitti, take it easy
[08:12] <jonh_wendell> pitti, i do a lsdiff <package>.diff and got nothing
[08:12] <pitti> these steps are the general method how any patch is handled
[08:12] <Seveas> jonh_wendell, zcat package.diff.gz | lsdiff
[08:12] <pitti> jonh_wendell: that won't work in that form - lsdiff -z package.diff.gz
[08:13] <pitti> jonh_wendell: -z is for 'accept gzipped files', source packages have a diff.gz, not a .diff
[08:13] <davmor2>   /ignore #ubuntu-classroom JOINS QUITS
[08:13] <pitti> davmor2: 'mind the gap' :)
[08:13] <pitti> jonh_wendell: settled? or still unclear?
[08:14] <jonh_wendell> pitti, ok, done
[08:14] <pitti> in general we want the following diff options:
[08:14] <pitti> -N -> include new files
[08:14] <pitti> -u -> unified patches (context diffs are ugly)
[08:14] <pitti> -r -> recursive
[08:14] <pitti> -p -> bonus, you can see the name of the affected function in the patch
[08:14] <pitti> does anyone have a question about the principle method?
[08:14] <jonh_wendell> pitti, about cron, are you showing a wrong way to package?
[08:14] <pitti> (I know it's heavy, sorry, that's live; promised, it'll get easier)
[08:14] <pitti> jonh_wendell: well, it's not exactly 'wrong'
[08:14] <pitti> jonh_wendell: as long as the package is not heavily modified, or Debian/Ubuntu is essentially the upstream, it's fine
[08:15] <dieterd> one wrong letter - a mess afterwards
[08:15] <pitti> but having all patches in a single big lump makes it next to impossible to send stuff upstream, or tell which bit belongs to what
[08:15] <mwicki> does anybody know how to install e debianpaket whitout root-permission, is it possible to install a debian-paket in a directory??
[08:15] <pitti> jonh_wendell: also, the tendency is that packages which have 'always' been there, have more 'archaic' build systems and no patch system
[08:16] <Jon> mwicki: you can unpack it using dpkg-deb -x <package> <directory> as any user who can write to <directory>
[08:16] <pitti> where as most recently packaged stuff uses a standard packaging system with a standard patch system, now that they are invented
[08:16] <Jon> mwicki: be warned, though, that doesn't run the pre or post install scripts
[08:16] <mwicki> but it runs???
[08:16] <pitti> mwicki: do you need to do that for patching?
[08:16] <pitti> mwicki: it most probably won't work
[08:16] <Jon> mwicki: if it's a simple program then you could then run the binaries in it
[08:17] <Seveas> mwicki, jon: the session is busy enough already, I'd appreciate it if you stick to the topic
[08:17] <pitti> ok, let's go back to patching udev - an EXAMPLE! \o/
[08:17] <pitti> open a shell, ready your fingers :)
[08:17] <pitti> udev example 1, let's create a new patch 90_penguins.patch:
[08:17] <pitti>   cd /whereever/you/unpacked/the/source/udev-093
[08:17] <pitti>   cp -a . /tmp/old
[08:17] <pitti>   pushd /tmp/old
[08:17] <pitti>   debian/rules patch
[08:17] <pitti>   cp -a . /tmp/new; cd ../new
[08:17] <pitti> that's the preparatory part, now we have a directory we can hack in
[08:17] <mwicki> i tried to install in the university a paket, where i of corse dont have root permission
[08:17] <pitti> mwicki: #ubuntu, please
[08:18] <pitti> mwicki: or #ubuntu-classroom-chat
[08:18] <mwicki> sorry
[08:18] <pitti> let's do a braindead modification
[08:18] <pitti>   sed -i 's/Linux/Penguin/g' README
[08:18] <pitti> ^ of course you can also use a normal editor
[08:18] <pitti> I just use sed so that you can copy&paste the commands without any interactive stuff
[08:19] <pitti> and now we create a patch between the reference and our new tree
[08:19] <pitti>   cd ..
[08:19] <pitti>   diff -Nurp old new > 90_penguins.patch
[08:19] <pitti>   popd
[08:19] <pitti>   rm -rf /tmp/old /tmp/new
[08:19] <pitti>   mv /tmp/90_penguins.patch debian/patches
[08:19] <pitti> (Ignore the 'recursive directory loop' warnings)
[08:19] <jonh_wendell> pitti, what does pushd do?
[08:20] <pitti> jonh_wendell: 'pushd foo' is like 'cd foo', but remembers the last dir and pushes it onto a stack
[08:20] <pitti> if you then do 'popd', it will return to the directory you have been in when you did 'pushd'
[08:20] <cbx33> cool
[08:20] <StaCk> isn't it like cd - ?
[08:21] <pitti> StaCk: no, that will go only to the previous dir
[08:21] <pschulz01> hehe.. Now with SEPenguin support.
[08:21] <StaCk> uh your right
[08:21] <lara22> hi guys
[08:21] <ecki> hey
[08:21] <pitti> StaCk: you can stack multiple pushd's on top of each other, and allow 'cd' in between
[08:21] <pitti> Now take a look at your shiny new debian/patches/90_penguins.patch.
[08:21] <pitti> *uff* :)
[08:21] <cbx33> pitti, wow that's both useful and scary
[08:21] <pitti> after that, if you do 'debian/rules patch', you'll see that the patch applies cleanly
[08:21] <pitti>
[08:22] <pitti> so, obviously that's not the end of the wisdom, but if you do these steps a couple of times, you should get a feeling for how to create the most complicated patch conceivable
[08:22] <pitti> so this procedure is the life safer if anything else fails
[08:22] <pitti> questions so far?
[08:22] <pschulz01> pitti: cd new?
[08:22] <pitti> pschulz01: 'cp -a . /tmp/new; cd ../new'
[08:22] <dieterd> result is then a new cd with included patches?
[08:23] <pitti> pschulz01: we applied all previous patches in /tmp/old, then copied /tmp/old to /tmp/new, and hacked our stuff in /tmp/new
[08:23] <pitti> dieterd: the result after all of these steps is a single new file debian/patches/90_penguins.patch
[08:23] <pitti> dieterd: the commands above removed the temporary /tmp/old and /tmp/new trees
[08:23] <pschulz01> pitti: Neet to copy 90_penguins.patch to new/debian/patches
[08:23] <pitti> pschulz01: no, it shouldn't go to new
[08:24] <pitti> pschulz01: it should go to /whereever/you/unpacked/the/source/udev-093
[08:24] <pitti> (the original source dir, not the temporary working copies in /tmp)
[08:24] <pschulz01> pitti: Ahh.. ok.
[08:24] <pitti> any other difficulties? shall I copy the commands again as a block for clarity?
[08:24] <danilos> pitti: just use the parentheses to make stuff "clearer", like "cp -a /wherever/you/unpacked /tmp/old; (cd /tmp/old; blah...; cd /tmp/new; foo...); rm -rf /tmp/old /tmp/new" :)
[08:25] <pitti> danilos: hm, I use newlines for that
[08:25] <pitti> Pretty much work, isn't it? Since this happens pretty often, I created a very dumb helper script 'dsrc-new-patch' for this purpose.
[08:25] <pitti> that's the script you downloaded as part of the preparations
[08:26] <pitti> so, please remove debian/patches/90_penguins.patch again
[08:26] <pitti> yes, I know it was hard to do, but for the sake of demonstration :)
[08:26] <cbx33> pitti, that's the only way to learn dude
[08:26] <pschulz01> pitti: OK.. that's better.
[08:26] <pitti> so, with Pitti's Hackish Script (tm):
[08:26] <pitti>   dsrc-new-patch 90_penguins.patch
[08:26] <pitti>   sed -i 's/Linux/Penguin/g' README
[08:26] <pitti>   <press Control-D to leave the subshell>
[08:27] <pitti> that looks slightly better, doesn't it?
[08:27] <pitti> but I had to torture you with the close-to-the-metal method for the sake of understanding.
[08:27] <at2000> in which dir to run the script?
[08:28] <pitti> at2000: in the root of the unpacked source tree
[08:28] <pitti> at2000: to conform with my previous example, /whereever/you/unpacked/the/source/udev-093
[08:28] <at2000> ok
[08:28] <at2000> then it should be "../dsrc-new-patch"
[08:28] <pitti> at2000: oh, right, you have to specify the path to the scrpit
[08:28] <dieterd> cu
[08:28] <jonh_wendell> pitti, is this script the same of cdb... showed yesterday?
[08:28] <pitti> I have it in my ~/bin, conveniently
[08:28] <pitti> jonh_wendell: no, not at all
[08:29] <pitti> jonh_wendell: I'll come to that
[08:29] <pschulz01> Hmm.. where do I find 'debclean'?
[08:30] <pitti> pschulz01: sudo apt-get install devscripts
[08:30] <pschulz01> pitti: Ta.
[08:30] <pitti> ^ for everyone else, too, sorry; fortgot to mention that
[08:30] <pitti> forgot, too
[08:30] <jonh_wendell> pitti, before run  dsrc-new-patch 90_penguins.patch  we have to clean dir, right?
[08:30] <pschulz01> pitti: It was in the 'recommends'
[08:30] <pitti> jonh_wendell: if you just unpacked the tree, it shuoldn't be necessary
[08:31] <pitti> ok, we need to go on
[08:31] <pitti>  let's stay at udev a bit and do the second example
[08:31] <pitti> I promise, this will be the last complicated issue in this lesson
[08:31] <pitti> but it might teach you to never ever do a package without a proper patch system :)
[08:31] <pitti> dsrc-new-patch is currently too dumb to edit existing patches, or to put patches somewhere else than the top of the patch stack. If you need this, then you need to do the manual approach. Assume we want to edit 50-result-whitespace.patch.
[08:31] <jonh_wendell> pitti, as i've run debian/rules patch with 90-penguim, i have to clean it
[08:31] <pitti> jonh_wendell: ah, right
[08:32] <pitti> This already existing patch 50-result-whitespace.patch does not depend on the previous patches, so it's a bit easier that way, too:
[08:32] <pitti>   cd /whereever/you/unpacked/the/source/udev-093
[08:32] <pitti>   cp -a . /tmp/old
[08:32] <pitti>   pushd /tmp/old
[08:32] <pitti>   cp -a . /tmp/new; cd ../new
[08:32] <pitti> nothing new so far
[08:32] <pitti> but note that we did not apply any patch (since we assume that 50-result-whitespace.patch does not depend on its predecessors)
[08:33] <pitti>   patch -Nlp1 < debian/patches/50-result-whitespace.patch
[08:33] <pitti> above will apply the current version of the patch, so that you can edit it
[08:33] <pitti> now we have the *original* change in /tmp/new, which we now want to modify
[08:33] <pitti> so, let's do another braindead change:
[08:33] <pitti>   sed -i '1 s/$/***** HELLO WORLD ****/' udev_selinux.c
[08:34] <pitti> or any other change you quickly want to do in your favourite editor, of course
[08:34] <pitti> so, again we now have the original version in /tmp/old, and our old and new patch in /tmp/new
[08:34] <pitti> so let's do the patch:
[08:34] <pitti>   cd ..
[08:34] <pitti>   diff -Nurp old new > 50-result-whitespace.patch
[08:34] <pitti>   popd
[08:34] <pitti>   mv /tmp/50-result-whitespace.patch debian/patches
[08:34] <pitti>   rm -rf /tmp/old /tmp/new
[08:34] <pitti> Now debian/patches/50-result-whitespace.patch contains both the original change and our modification of the first line of the source file.
[08:35] <pitti> but promised, from now on it will get really easy :)
[08:35] <pitti> any questions? is the issue of patch dependencies clear to everyone?
[08:35] <jonh_wendell> pitti, how do i know if a patch depends on others or not?
[08:35] <pitti> jonh_wendell: in general you should assume that each patch depends on the previous one
[08:36] <pitti> jonh_wendell: they *don't* if they patch a file that hasn't been patched before
[08:36] <pitti> or they patch it on a completely different position
[08:36] <pitti> e.g., if debian/patches/1_foo.patch changes foo.c, line 5
[08:36] <pitti> and debian/patches/2_bar.patch changes foo.c at line 6
[08:36] <pitti> then patch 2 definitively depends on patch 1
[08:37] <jonh_wendell> pitti, ok
[08:37] <at2000> is unified patch format better eliminating patch dependency?
[08:37] <pitti> jonh_wendell: a (non-solid) rule of thumb is: if you can apply the patch alone on the unmodified source tree, it's independent
[08:37] <pitti> at2000: no, not at all
[08:37] <pschulz01> pitti: Back with you.. it had to do a 'debian/rules clean' to cleanup the source.
[08:37] <pitti> unidiff vs. context diff is purely a matter of readability
[08:38] <at2000> ic
[08:38] <jonh_wendell> pitti, will you talk about cdbs-edit-patch which was showed to us yesterday?
[08:38] <pitti> patch dependency is an inherent property of patches modifying the same thing
[08:38] <pitti> not a question of a particular patch format
[08:38] <pitti> jonh_wendell: I will, it's the next topic
[08:38] <pitti> anything settled so far?
[08:38] <pitti> Since this is so hideously complicated, patch systems were invented to aid you with that.
[08:38] <pitti> Let's look at the most popular ones now (they are sufficient to allow you to patch about 90% of the archive's source packages; for the rest you have to resort to the manual approach above).
[08:39] <pitti> == pmount: cdbs with simple-patchsys ==
[08:39] <pitti> cdbs' simple-patchsys.mk module matches its name, it has no bells and whistles whatsoever. However, it is pretty popular since it is sufficient for most tasks, and long ago I wrote a script 'cdbs-edit-patch' which most people can live with pretty well. This script is contained in the normal cdbs package.
[08:39] <pitti> You just supply the name of a patch to the script, and depending on whether it already exists or not, it will create a new patch or edit an existing one.
[08:39] <pitti> simple-patchsys is the cdbs module that 90% of all cdbs-using source packages will use
[08:39] <pitti> BTW, "cdbs-edit-patch" is slightly misleading, since it actually only applies to simple-patchsys.mk. You can also use other cdbs patch system plugins, such as dpatch or quilt.
[08:40] <pitti> everyone please look in debian/patches, debian/rules of pmount to get a feeling how it looks like
[08:40] <pitti> so, let's mess up pmount a bit
[08:40] <pitti> and add a new patch
[08:40] <pitti>   cd /whereever/you/unpacked/the/source/pmount-0.9.13
[08:40] <pitti>   cdbs-edit-patch 03-simple-readme.patch
[08:40] <pitti>   echo 'This should document pmount' > README
[08:40] <pitti>   <press Control-D to leave the subshell>
[08:40] <pitti> easy, isn't it?
[08:41] <pitti> check debian/patches/03-simple-readme.patch for the result
[08:41] <pitti> this will take care of applying all patches that need to be applied, can change patches in the middle of the stack, and also create new ones
[08:41] <pitti> Editing an already existing patch works exactly the same way, so I won't give a demo
[08:42] <jonh_wendell> cdbs-edit-patch rocks
[08:42] <pitti> yeah, unfortunately it only really works for packages that use cdbs
[08:42] <jonh_wendell> pitti, how do i know if a package uses cdbs?
[08:43] <pitti> which a good part of Gnome-related packages do
[08:43] <pschulz01> pitti: What does cdbs stand for?
[08:43] <pitti> jonh_wendell: debian/rules includes files from /usr/share/cdbs
[08:43] <pitti> jonh_wendell: and build-depends on cdbs
[08:43] <pitti> pschulz01: common debian build system
[08:43] <pschulz01> Ta
[08:43] <pitti> it's a very modular abstraction of boilerplate build rules, patch systems, etc.
[08:44] <at2000> when I cdbs-edit-patch the same diff, it results in 2 diffs concatenated in the same file?
[08:44] <pitti> at2000: if you edit two different files, yes
[08:44] <pitti> at2000: in general, it will merge the old and new patch
[08:45] <at2000> perhaps I've done something wrong
[08:45] <jonh_wendell> pitti, when we make a patch, should we add entries in debian/changelog file too?
[08:45] <pschulz01> pitti: This makes creating patches very easy :-)
[08:45] <pitti> jonh_wendell: if you intend to publish this, yes, by all means
[08:45] <pitti> pschulz01: \o/
[08:46] <pitti> can I go on?
[08:46] <jonh_wendell> sure
[08:46] <pitti> time pressure...
[08:46] <pitti> == ed: dpatch ==
[08:46] <pitti> dpatch is a pretty robust and proven patch system which also ships a script 'dpatch-edit-patch'
[08:46] <pitti>  The two most important things you should be aware of:
[08:46] <pitti>  * dpatch does not apply debian/patches/*, but instead applies all patches mentioned in debian/patches/00list, in the mentioned order. That means that you do not have to rely on asciibetical ordering of the patches and can easily disable patches, but you have to make sure to not forget to update 00list if you add a new patch.
[08:46] <pitti> (forgetting to update 00list is a common cause of followup uploads)
[08:46] <pitti>  * dpatch patches are actually scripts that are executed, not just patches fed to 'patch'. That means you can also do fancy things like calling autoconf or using sed in a dpatch if you want.
[08:47] <pitti> using dpatch for non-native patches is rare, and normally you do not need to worry about how a .dpatch file looks like
[08:47] <pitti> but I think it's important to mention it
[08:47] <pitti> so if you ever want to replace *all* instances of Debian with Ubuntu in all files, write a dpatch with a small shell script that uses sed
[08:47] <pitti> instead of doing a 300 KB static patch which won't apply to the next version anyway
[08:47] <pitti> The manpage is very good and has examples, too, so I will only give an example here:
[08:47] <Seveas> smart
[08:47] <pitti> This will edit an already existing patch and take care that all previous patches are applied in order:
[08:48] <pitti>   cd /whereever/you/unpacked/the/source/ed-0.2
[08:48] <pitti>   dpatch-edit-patch 05_ed.1-warning-fix
[08:48] <pitti>   <edit stuff, press Ctrl+D>
[08:48] <pitti> so that's exactly like cdbs-edit-patch
[08:48] <pitti> well, dpatch-edit-patch even has shell completion (!)
[08:48] <pitti> s/shell/tab/
[08:48] <pitti> ok, now we edited a patch, that's pretty easy, right?
[08:49] <pitti> now let's create a new one; this is different from cdbs-e-p, due to the explicit '00list' file
[08:49] <pitti>   dpatch-edit-patch foo.dpatch 06_testsuite-Makefile.dpatch
[08:49] <pitti>   <edit stuff, press Ctrl+D>
[08:49] <pitti>   echo foo.dpatch >> debian/patches/00list
[08:49] <pitti> ^ this will append 'foo.dpatch' to debian/patches/00list
[08:50] <pitti> This will create a new patch foo.dpatch relative to the already existing 06_testsuite-Makefile.dpatch. If your patch is very confined and does not depend on other patches, you can leave out the second argument.
[08:50] <pitti> alright?
[08:50] <pitti> there is actually yet another patch system I wanted to introduce (quilt), but I'll skip this for time reasons
[08:51] <Seveas> you could continue after simon finished talking bugs
[08:51] <pitti> maybe we can get to that on Thursday, or I'll explain it separately
[08:51] <pitti> and there is existing documentation anyway
[08:51] <pitti> so, just some more theoretic words, which you can use to calm down your fingers :)
[08:51] <pitti> [08:52] <pitti> As you saw, Debian source packages do not have any requirements wrt. structure, patch systems, etc., other source package systems like SRPM are much stricter wrt that. This of course means more flexibility, but also much more learning overhead.
[08:52] <pitti> As a member of the security team I can tell tales of the pain of a gazillion different source package layouts... :)
[08:52] <pitti> Therefore some clever people sat together the other day to propose a new design which would both give us a new and unified source package and patch system that uses bzr (with a quilt-like workflow). This would also integrate packages and patches much better into Launchpad and revision control in general.
[08:52] <pitti> Please take a look at https://wiki.ubuntu.com/NoMoreSourcePackages if you are interested in this.
[08:52] <pitti> ah, and of course:
[08:53] <pitti> [08:53] <pitti> (apart from the obligatory channel log from fabbione)
[08:53] <pitti> There is also a wiki page https://wiki.ubuntu.com/MOTU/School/PatchingSources which provides most of above information in a more convenient format. However, it might be slightly out of date (it's from dapper times). Feel free to update the page and and add missing bits.
[08:53] <jonh_wendell> pitti, we should add manually foo.dpatch in 00list, right?
[08:53] <pitti> so let's spend the rest of the time for Q&A
[08:53] <pitti> fire away :)
[08:53] <pitti> jonh_wendell: right
[08:53] <pitti> jonh_wendell: that's what I did with
   echo foo.dpatch >> debian/patches/00list
 ^ this will append 'foo.dpatch' to debian/patches/00list
[08:53] <at2000> what are pros and cons of quilt?
[08:54] <jonh_wendell> sorry
[08:54] <pitti> at2000: hm, matter of taste, mainly
[08:54] <pitti> at2000: the patching workflow is not really different
[08:55] <snail> pitti: wiki page looks really good
[08:55] <at2000> so why not just stick to cdbs, what most packages use?
[08:55] <pitti> the wiki page explains quilt as well, BTW
[08:55] <ajmitch> pitti: has there been any more progress on the NoMoreSourcePackages spec?
[08:55] <pitti> so if you got a general feeling for the topic now, you should be able to read the wiki page
[08:55] <pitti> at2000: we cannot prescribe Debian to change source packages to our wishes
[08:56] <pitti> at2000: also, cdbs is not the unanimous solution for Ubuntu devs either
[08:56] <pitti> some people really hate it
[08:56] <at2000> ic
[08:56] <pitti> ajmitch: bzr-wise, yes, but there's no LP support yet
[08:56] <pitti> ajmitch: and it won't come in the near future, there are much more pressing TODOs for soyuz ATM
[08:56] <pitti> I know it was hard stuff, I hope I didn't kill too many listeners
[08:56] <pitti> any feedback for me?
[08:57] <jonh_wendell> pitti, thank you
[08:57] <pitti> (but patching source packages is not easy...)
[08:57] <amnesia> pitti: you did good, thanks
[08:57] <pitti> amnesia: were you able to follow the examples? I didn't see many questions
[08:57] <snail> pitti: i know this is a little off topic, but what's the recommended form of documentation for packages (ANSI C, commandline app, internationalisation crucial) ?
[08:57] <pschulz01> pitti: I thought it was good.. I've bee through the wiki page, but the step by step examples with real packages was very useful.
[08:57] <Seveas> pitti, you were great :)
[08:57] <jonh_wendell> pitti, any talk about debdiff? is it a diff of a diff?
[08:58] <pitti> snail: that's a very broad question, let's do that in #u-c-chat
[08:58] <amnesia> pitti: I was just reading, I'm in CS/IT myself so it was enough for me, sorry
[08:58] <ajmitch> pitti: right, I hadn't seen any work done on the bzr plugin that I heard would only take a few days to do :)
[08:58] <pitti> jonh_wendell: 'debdiff' is a tool that gives you a diff between two complete source packages
[08:58] <thekorn> pitti: thanks nice job
[08:59] <pitti> jonh_wendell: so, if you debdiff two source packages which include patches, then yes, you'll get diffs of diffs
[08:59] <amnesia> pitti: but from my side, yes I could follow you pretty good :)
[08:59] <ajmitch> pitti: the session was good, for the bits I was watchign :)
[08:59] <pitti> thanks guys
[08:59] <at2000> thanks martin
[08:59] <jonh_wendell> 1 hour is very short :(
[09:00] <amnesia> yeah but it should be good for a starter
[09:00] <pitti> would it have been better to first explain the tools and then do the manual approach?
[09:01] <jonh_wendell> oh, we have one more talk, great
[09:01] <amnesia> pitti: thursday is the same?
[09:01] <pitti> amnesia: more or less
[09:01] <Seveas> pitti, no, doing manual first is definitely better
[09:01] <pitti> followup discussion of patch systems -> #ubuntu-classroom-chat, please
[09:01] <Seveas> then you know what the tools are magically doing
[09:01] <pitti> Seveas: that's what I thought, too
[09:02] <amnesia> pitti: I would keep this order
[09:02] <amnesia> yeah exactly
[09:02] <pitti> ok
[09:02] <pitti> thanks everyone
[09:02] <ajmitch> thanks pitti
[09:02] <jonh_wendell> thanks pitti !
[09:02] <amnesia> maybe point this out, that "you need to do this now to know what really needs to be done in the background"
[09:02] <pitti> amnesia: right
[09:03] <amnesia> and you always said it will just get easier :)
[09:04] <amnesia> so you made the listeners feel good, that's important
[09:05] <sfllaw> Good afternoon.
[09:06] <sfllaw> Welcome to my talk about the Ubuntu BugSquad.
[09:06] <Bourlotieris> hello
[09:06] <sfllaw> For the purposes of clarity, please limit discussions to #ubuntu-classroom-chat.  If you want to ask a question, just write "sfllaw: I have a question about..." in #ubuntu-classroom-chat and I'll answer it at the approriate juncture.
[09:06] <sfllaw> Thanks!
[09:06] <sfllaw> ---------------------------------------
[09:06] <sfllaw> Ubuntu is one of the most popular GNU/Linux distributions out there.  And it also has one of the smallest development teams for its size.
[09:06] <sfllaw> The secret to this is huge community involvement.  We have hundreds of people who help with packaging, translations, technical writing, and bug management.
[09:07] <sfllaw> And boy do we have a lot of bugs.  About 300 to 400 new bug reports get filed every day from users, from stable releases like Dapper to bleeding edge stuff from Feisty.
[09:07] <sfllaw> The first people to look at these reports are the BugSquad.  We do a very important task, drinking from this firehose.  And that's to make sure that the reports that remain in the bug tracking system are useful.
[09:07] <sfllaw> You can find our bug tracking system at https://launchpad.net/distros/ubuntu/+bugs
[09:07] <sfllaw> Right now, it holds over 20000 open bug reports, spread across the entire distribution.  That includes main, restricted, universe, and multiverse.
[09:07] <sfllaw> That's a lot of bugs.  The source of these reports can be found here: http://tinyurl.com/yf4hq9
[09:07] <sfllaw> These are untriaged reports: ones which have never had a human eye look at them.  It's likely that they are missing information, duplicate another report, are filed against the wrong package, etc.  Or, if you're lucky, they're perfect.
[09:07] <sfllaw> :)
[09:08] <sfllaw> To triage a bug report, you need to do a few things.
[09:08] <sfllaw> First you have to determine if it's actually a bug.  The easiest ones have crash reports in them.  Let's go find one.
[09:08] <sfllaw> To start, we go to http://launchpad.net  Click on "The Ubuntu distribution"
[09:08] <sfllaw> In the search box, let's look for a popular package.  Bash is a good one to try, so let's ask for that.
[09:09] <sfllaw> Click on 'Source Package "bash" in Ubuntu' to be taken to its package page.
[09:09] <sfllaw> This shows you Bash within the context of the Ubuntu distribution.  Bash also has another page, a product page, which we won't look at right now.
[09:09] <sfllaw> In the left sidebar, you should see a "Bugs" link.  Click on that and you'll be taken to the bug tracker.  This will list all the bugs inside bash right now.
[09:09] <sfllaw> There are quite a few untriaged bugs, but they are intermixed with triaged ones.  Let's narrow down our search to only show untriaged ones.  Start by clicking the "Advanced search" link.
[09:09] <sfllaw> You want to make sure that:
[09:09] <sfllaw>   Status = Unconfirmed only
[09:09] <sfllaw>   Importance = Undecided only
[09:09] <sfllaw>   Assignee = Nobody
[09:10] <sfllaw> Click the "Search" button.
[09:10] <sfllaw> You should end up at http://tinyurl.com/yawhpj which gives you a nice list of bugs to look at.
[09:10] <sfllaw> Bug 57413 looks like a promising crash.  Click on its description and it will open up.  You can also get to this bug by going to http://launchpad.net/bugs/57413
[09:10] <sfllaw> You see that the bug reporter has included his crash dump, which was caught by apport, our automated crash profiler.  But Longer hasn't really given us enough information to solve the problem.
[09:11] <sfllaw> Here's the minimum information for a complete bug report:
[09:11] <sfllaw>   1. Version of the software.  Is it in Dapper, Edgy, Feisty?  What about a specific version number?
[09:11] <sfllaw>   2. Steps to reproduce the bug.
[09:11] <sfllaw>   3. What was expected to happen.
[09:11] <sfllaw>   4. What actually happened.
[09:11] <sfllaw> Since this bug is incomplete, we'll want to ask for more information.  You do that by taking responsibility for the bug and having a conversation with the reporter.
[09:11] <sfllaw> Implicitly, we know the answers to 3 and 4, because Bash crashed unexpectedly.
[09:12] <sfllaw> And the crash report has the version of bash buried inside (3.1-5ubuntu1).
[09:12] <sfllaw> Still, we need to ask for reproduction steps.
[09:12] <sfllaw> If you're logged in, you can click on the "bash (Ubuntu)" task table up near the top.  This allows you to modify the state of the bug.
[09:12] <sfllaw> There are some fields there:
[09:12] <sfllaw>   Package: this is the source package of the bug.  Bash is correct for this one.
[09:12] <sfllaw>   Status: change this to Needs Info.  This means other people won't try to triage this bug.
[09:12] <sfllaw>   Assigned to: Me.  You're claiming responsibility for having a conversation with the reporter.
[09:12] <sfllaw>   Comment on this change: Here we should ask the reporter for more information.
[09:12] <sfllaw>   E-mail me about changes to this bug report: Yes.  This will subscribe you to any new comments about this report.
[09:13] <sfllaw> shawarma points out that apport, which generated this crash dump, wasn't in Dapper.
[09:13] <sfllaw> So it must be an Edgy bug.
[09:13] <sfllaw> But apport also tells you the difference between an Edgy bug and a Feisty bug.
[09:14] <sfllaw> at2000 asks: who should modify these fields?
[09:14] <pitti> (in the DistroRelease: field)
[09:14] <sfllaw> You, as the triager, get to set these fields.
[09:15] <at2000> so someone officially in the BugSqad team?
[09:15] <sfllaw> Yes.  In fact, you get to set them before you join BugSquad.
[09:15] <sfllaw> Although it's good form to be know how to change them properly before you start doing so.  :)
[09:15] <at2000> ic
[09:16] <sfllaw> But that's why you're here!
[09:16] <sfllaw> So...
[09:16] <sfllaw> You've set the proper meta-data on the bug and have taken responsibility.
[09:16] <sfllaw> In the comment, we would ask for the version of Bash:
[09:16] <sfllaw>   "Hi Longer.  Could you please describe the precise steps you performed to crash bash?  Thanks."
[09:16] <sfllaw> Click "Save Changes" and you're done.
[09:16] <sfllaw> When you get an e-mail from Longer responding to your question with the appropriate steps, the bug can be considered complete.  You've got information on how to reproduce it and there's even a handy log file for a developer to look at.
[09:17] <sfllaw> We can now pass this on to the development team to fix.
[09:17] <sfllaw> Click "bash (Ubuntu)" again and change:
[09:17] <sfllaw>   Status = Confirmed
[09:17] <sfllaw>   Assigned to = Nobody
[09:17] <sfllaw> Click "Save Changes".
[09:18] <sfllaw> rulus asks: where ends the task of the Bug Squad team? here?
[09:18] <sfllaw> The BugSquad team actually works on all parts of bugs.
[09:18] <sfllaw> However, the job of a triager ends here.
[09:18] <rulus> ah, ok
[09:18] <sfllaw> Basically, it's like the first response you get at a hospital.
[09:19] <rulus> i see
[09:19] <sfllaw> You want to manage the huge flow of incoming bugs so that people fixing them aren't overwhelmed.
[09:20] <sfllaw> La_PaRCa asks: is it part of the triager work to mark duplicates?
[09:20] <sfllaw> Yes, it is.
[09:20] <sfllaw> I'm going to get to that later.
[09:20] <sfllaw> Let's say you encounter a bug report that isn't a bug at all.
[09:21] <sfllaw> Perhaps it is a user asking for help on installing software.  Like a request to be taught how to use synaptic.
[09:21] <sfllaw> Or perhaps it is a user asking for a new feature to be implemented.
[09:22] <siretart>
[09:22] <sfllaw> You can distinguish between features and bugs this way.
[09:22] <sfllaw> A feature request is a wish for new functionality that the program isn't expected to do.
[09:23] <sfllaw> Whereas a bug is where the program fails in some way.  It obviously should be doing something more correct.
[09:23] <sfllaw> You can respond to these by:
[09:23] <sfllaw> Setting Status = Rejected
[09:23] <sfllaw> And writing them a nice note in the comment explaining why it was not a valid bug.
[09:24] <sfllaw> You can get templates of these nice notes at https://wiki.ubuntu.com/Bugs/Responses
[09:24] <sfllaw> But you are welcome to put in your own personal touches.  Just remember to be friendly and polite, not terse.
[09:24] <sfllaw> Smiffeh asks: should you build up some serious experience with triaging before you apply to join the bugsquad?
[09:25] <sfllaw> No, you don't have to.  You can start in BugSquad right now.
[09:25] <sfllaw> Acceptance is automatic and we'd love to teach you the ropes.
[09:25] <sfllaw> Bourlotieris asks: I have a question about how do you join the Bugsquad team
[09:26] <sfllaw> You can join by:
[09:26] <sfllaw> - Joining the #ubuntu-bugs channel
[09:26] <sfllaw> - Getting a Launchpad account
[09:26] <sfllaw> - Applying to enter at https://launchpad.net/people/bugsquad
[09:27] <sfllaw> Grishkin asks: Is there a special ubuntu team for making new bugs?
[09:27] <Grishkin> :)
[09:27] <sfllaw> In order to report a bug, you don't need anything but a Launchpad account.
[09:27] <sfllaw> See https://help.ubuntu.com/community/ReportingBugs for how to file a bug report
[09:28] <sfllaw> davmor2 asks: do you need any technical or programing skills to join the bug squad
[09:28] <sfllaw> It helps, but you don't have to.
[09:29] <sfllaw> Even if you understand nothing about computers, there are some bugs that you can help out with.
[09:29] <sfllaw> They may be more difficult to find, but we are working on making it simpler.
[09:29] <sfllaw> For instance, you can verify that "yes, there is a typo in this documentation".
[09:29] <sfllaw> And you can try to reproduce bugs.
[09:29] <sfllaw> And gather debugging information that users haven't yet provided.
[09:30] <sfllaw> Another way to help out if you don't have a lot of technical knowledge, but enough to understand how a program _should_ work, is to look for duplicates.
[09:30] <davmor2> sfllaw: that was where I was assuming you may need some skills knowing what to ask for
[09:31] <sfllaw> In order to gather debugging information, you will want to read the http://wiki.ubuntu.com/DebugginProcedures page.
[09:31] <sfllaw> It describes various procedures for various packages.
[09:31] <sfllaw> We add documentation to that all the time.
[09:31] <sfllaw> And we'd love it if other people helped add to it as well.
[09:31] <rulus> it's https://wiki.ubuntu.com/DebuggingProcedures
[09:32] <sfllaw> Curse my poor speeling.
[09:32] <sfllaw> Moving on...
[09:32] <sfllaw> A large class of reports are duplicates.  These are filed by people who did not look or could not find a bug report identical to their problem.  So they filed a new one.  But looking through the bug tracking system, we can spot quite a few if we take some time.
[09:32] <sfllaw> For instance, let's look at the Totem's list of bugs: https://launchpad.net/distros/ubuntu/+source/totem/+bugs
[09:32] <sfllaw> There's a bug about screen blanking while watching movies, http://launchpad.net/bugs/66257
[09:32] <sfllaw> It has one bug marked as duplicate.  You can find a list of duplicates in the left sidebar.  That one is http://launchpad.net/bugs/73029
[09:33] <sfllaw> If someone filed a new bug that was exactly the same as this one, you could click on the "Mark as Duplicate" link in the left sidebar, and enter "66257" as the bug number.
[09:33] <sfllaw> You can find new bugs by looking at the big list of untriaged bugs.
[09:33] <sfllaw> Or you can join #ubuntu-bugs and listen as Ubugtu rattles off new bugs every few minutes.
[09:33] <sfllaw> It says things like this:
[09:34] <sfllaw> New bug: #73643 in gaim (main) "Gaim crashes while getting roomlist" [Undecided,Unconfirmed]  http://launchpad.net/bugs/73643
[09:34] <sfllaw> This tells you that a new bug has been filed for the gaim source package.
[09:34] <sfllaw> Gaim lives in main.
[09:34] <sfllaw> And provides a description of what's wrong.
[09:34] <sfllaw> Plus a handy URL to the bug.
[09:35] <sfllaw> samge1 asks: should trivial bugs (like a typo) be submitted as a  bug or is it better fix them right away somehow (like a new suggestion for a translation)?
[09:35] <sfllaw> It is best to file a bug report and point to a fix.
[09:36] <sfllaw> This fix could be a new translation in Rosetta, or a patch attached to the bug report.
[09:36] <sfllaw> This way, your fix doesn't get lost if it is a priority.
[09:36] <sfllaw> If you are a developer, you are encouraged to use bugs to manage your fixes, even if you can uploda packages into Ubuntu.
[09:36] <sfllaw> That way, you don't forget what's on your TODO list.
[09:38] <sfllaw> finalbeta asks: What bugs should we report, I've reported hardware bugs (none got fixed), small software bugs (none get fixed), I've reported +-30 bugs in the last few months and only one crasher got fixed. Yet it will take 6 months before the fix will show up (in the next release). What bugs are the ubuntu people capable of handling?, should we just go upstream whenever possible? In short I mean, I should not bother reporting fglrx / a
[09:38] <sfllaw> It is worth reporting bugs both to Ubuntu and to upstream.
[09:38] <sfllaw> In fact, our bug tracking system has the capability to track upstream bugs.
[09:38] <mcg> ?
[09:39] <sfllaw> Ubuntu developers don't have a lot of resources, so we prefer to let upstream authors fix bugs unless they are critical.
[09:39] <amnesia> #ubuntu-classroom-chat
[09:39] <sfllaw> But we use the bug tracking system to monitor upstream bugs.  If an upstream has fixed something major, we will often backport that fix.
[09:39] <amnesia> sorry
[09:40] <sfllaw> The goal of a triager is to reduce the clutter in the bug tracking system.
[09:40] <sfllaw> You shouldn't be closing old bugs, as they might still be useful and relevant.
[09:40] <mcg> quit
[09:40] <mcg> exit
[09:40] <sfllaw> But new bugs coming in should be examined for duplicates.
[09:41] <sfllaw> This reduces the clutter in the bug tracking system.  You want to choose the definitive bug with the most complete information, and make all the other duplicates refer to it.  If information is scattered around, you can edit the description of the definitive bug.
[09:41] <LjL> mcg: /quit is the command you type if you want to leave the server, /part if you want to leave the channel
[09:41] <sfllaw> The description of a bug is mutable, so that you can summarize the discussion held in the comments.
[09:41] <sfllaw> This is really useful because difficult bugs may have pages and pages of comments.
[09:42] <sfllaw> Any bug can have its description edited, and a good summary saves people a lot of time sifting through the conversation.
[09:42] <sfllaw> To change the description, click the "Edit Description/Tags" link in the sidebar.  Try to clean up the description with a good summary of: Version, Reproduction steps, Expected result, Actual result, and a Diagnosis of the problem.
[09:42] <sfllaw> You should also make sure the Summary is something useful, so people browsing for duplicates can find a relevant bug easily.
[09:42] <sfllaw> Bad descriptions are: "Program crashes."
[09:42] <sfllaw> Good descriptions are: "Program crashes with 'Error 12: Can't find my brain on line 382.'"
[09:42] <sfllaw> A good description is easily searchable using keywords people would think of.
[09:43] <sfllaw> And error messages are good because they are often unique to the problem.
[09:43] <sfllaw> Click "Change" after updating the text.
[09:43] <TheCode> nabend!
[09:43] <sfllaw> a7p asks: what about #27810 - should this one be closed? Who does it if it should be done?
[09:44] <sfllaw> This is a good example of how Ubuntu bugs can be tied to upstream bugs.
[09:44] <sfllaw> If you look at the task table, you'll see three different lines.
[09:45] <sfllaw> libaio (Ubuntu)
[09:45] <sfllaw> upstart (Ubuntu)
[09:45] <sfllaw> libaio (Debian)
[09:45] <sfllaw> So the first two have to do with Ubuntu packages.
[09:45] <sfllaw> And the third has to do with Debian ones.
[09:45] <sfllaw> If I were going through this bug doing triage right now, I'd do the following things.
[09:45] <sfllaw> - Realize that it has nothing to do with upstart, and reject it.
[09:46] <sfllaw>   To do this, I click on the upstart (Ubuntu) task and set its status to Rejected.
[09:46] <sfllaw>   Like so.
[09:47] <sfllaw> - Notice that Fabio claims that this isn't a problem in Ubuntu because the brokenness was never imported.
[09:47] <sfllaw> - Test to make sure I cannot reproduce the problem.
[09:47] <sfllaw>   If everything works properly, I set libaio (Ubuntu)'s status to Rejected.
[09:48] <sfllaw> In order to add upstream tasks, you will note two links under the task table:
[09:48] <sfllaw> "Also affects: +Upstream... +Distribution..."
[09:48] <sfllaw> If a bug affects another distribution like Fedora, Guadalinux, or Debian, with its own packages, use the +Distribution link.
[09:49] <sfllaw> If a bug is caused by an upstream program's misbehaviour and is not a packaging bug, use the +Upstream link.
[09:50] <sfllaw> You will have to file the bug in the other bug tracker, but then you can paste that bug's URL in to the "Request fix in a..." page, which will link the bugs together.
[09:50] <sfllaw> Every day, the status of this bug will be updated with the upstream's status.
[09:50] <sfllaw> Plus, you can search for bugs which have been fixed by upstream.
[09:50] <sfllaw> davmor2 asks:  What is your description of security?  would it be the root password problem a while ago
[09:51] <sfllaw> A security bug is one that allows local or remote users to access data or privileges that they shouldn't normally be able to.
[09:51] <sfllaw> This definition is a bit flexible and up the discretion of the security team.
[09:51] <pitti> breezy's user password exposure definitively falls into this category
[09:51] <sfllaw> If you file a security bug, only the people subscribed to it will be able to see it.
[09:52] <sfllaw> rulus asks: how do you know it also affexts upstream?
[09:52] <pitti> sfllaw's definition is pretty good; I'd extend it to 'or allows a local/remote user to bring down a service'
[09:52] <keescook> the wiki page SecurityUpdateProcedures has some examples of what can qualify, too.
[09:53] <sfllaw> It's easy to tell whether a bug is caused by us.
[09:54] <sfllaw> if a package doesn't install, the description is incorrect, or something doesn't show up in a menu, then it's probably Ubuntu's fault.
[09:54] <sfllaw> If a program crashes or misbehaves, it's probably an upstream problem.  Especially if Google tells you that people using other distributions have the same problem.
[09:54] <rulus> ok, i see
[09:55] <sfllaw> It is usually a good idea to Google for your bug to see if:
[09:55] <sfllaw> - You can find other people with your problem.  Often, these things will show up on newsgroups or forums (like the Ubuntu Forums)
[09:55] <sfllaw> - You can find a bug in our bug tracking system already.
[09:56] <sfllaw> - You can find a bug in someone else's bug tracking system (like Debian, Fedora, OpenSuSE, etc.)
[09:56] <sfllaw> davmor2 asks:  does this mean you need to be running bugzilla too in order to cross reference?
[09:56] <sfllaw> You don't have to sign up for other people's Bugzilla if you don't want to.
[09:56] <sfllaw> You can concentrate on whatever packages you like.
[09:57] <sfllaw> But if you want to pitch in for a few days to help with Firefox bugs, you should probably sign up for the Firefox Bugzilla, so you can report bugs to them.
[09:57] <sfllaw> It makes a lot of sense to concentrate on a set of packages.  You can quickly become a local expert in some software.
[09:58] <sfllaw> davmor2 asks:  I have reported a lot of bugs which have been marked as duplicates due to me not being able to find anything similar is there a way to better search for a bug?
[09:58] <davmor2> sfllaw: I meant more to cross reference an ubuntu bug with a redhat bug
[09:59] <sfllaw> To cross-reference with Red Hat, you should have a Red Hat bugzilla account to file bugs into their system.
[09:59] <sfllaw> If the bug already exists, linking them together is free.
[09:59] <davmor2> okay
[09:59] <sfllaw> But to be polite, you should comment in the Fedora bug with the URL to the Ubuntu one.
[09:59] <sfllaw> That way, our distributions can work together to fix things.
[09:59] <sfllaw> For your other question about duplicates...
[09:59] <rasman> I had a problem with a new ATI card, how would I report a bug like that?  How would it be addressed?
[10:00] <davmor2> makes sense more devs that way
[10:00] <sfllaw> I've found the best way is to use Google.
[10:00] <Amaranth> haha, use Google to find launchpad bugs :)
[10:01] <sfllaw> But to be sure, I often browse all open bugs for a particular package and look for potential descriptions to match.
[10:01] <sfllaw> If you spend lots of time on a package, you will remember things that are similar.
[10:01] <sfllaw> Sadly, search in Launchpad is not as good as it could be.
[10:01] <sfllaw> We're running short on time.
[10:01] <sfllaw> For more information, please see https://wiki.ubuntu.com/HelpingWithBugs which describes how to help with bugs and how to join the BugSquad.
[10:01] <sfllaw> We hang out in the #ubuntu-bugs IRC channel on irc.freenode.net.
[10:01] <sfllaw> You can find help and encouragement (and hugs) there all the time.
[10:01] <sfllaw> Finally, I want to point out that we have an *UbuntuHugDay* scheduled for tomorrow.  If you want to start helping with bugs, that would be a great time to pitch in.
[10:02] <sfllaw> https://wiki.ubuntu.com/UbuntuHugDay
[10:02] <sfllaw> Thanks everybody!
[10:02] <sfllaw> We're out of time so I'll field questions in #ubuntu-bugs.
[10:02] <rulus> thanks for the explanation!
[10:02] <amnesia> sfllaw: good session
[10:02] <Cieffe> thanks sfllaw
[10:02] <La_PaRCa> sfllaw, thanks a lot
[10:02] <davmor2> sfllaw no next setion listed
[10:03] <sfllaw> Well, I guess I should close up shop.
[10:03] <sfllaw> nalioth: Ping? ^^^
[10:04] <nalioth> sfllaw: thanks for your time  :) we do love information  :)
[10:04] <davmor2> thanks
[10:04] <alefteris> thanks :)
[10:04] <Bourlotieris> Thank you, most compact session today
[10:05] <samge1> thanks man
[10:05] <silwol> thx sfllaw
[10:10] <kalon33> thanks sfllaw
[10:29] <tuxar> thanks for all you do for us !
[10:47] <test> quit
[10:48] <metatecque> test: you need to put a slash before quit if you want to quit


[06:08] <seb128> goood morning desktopers!
[06:32] <luna_> morning
[06:35] <duflu> Hi seb128 and luna_
[08:02] <Laney> guten morgen!
[08:02] <jibel> cpaelzer_, is there anything in latest libvirtd in groovy that could affect networking? I'm trying to figure out why suddenly I've no network inside the guest.
[08:03] <jibel> the guest is a focal live session with daily from yesterday
[08:06] <duflu> Hi Laney
[08:15] <Laney> moin duflu
[08:30] <seb128> hey duflu, Laney, jibel, how are you in a summer day?
[08:31] <duflu> seb128, it's winter but sunny. How are you?
[08:33] <seb128> duflu, I'm alright, hopefully having a 'normal' work day today and I can get some work done, though it's going to be over 30°C and melting in front of the keyboard sucks a bit
[08:33] <seb128> we have extra heat until tomorrow and then rain over the weekend :/
[08:33] <duflu> To be fair, a month into winter and we're only now below 20 degrees so it's OK
[08:35] <jibel> seb128, going well.enjoying the beach on the evening
[08:41] <seb128> jibel, :-)
[08:42] <duflu> jibel is winning June
[08:45] <Laney> moin seb128
[08:45] <Laney> bit sad that all the nice days are during work time and then the weekend sucks
[08:46] <seb128> indeed :/
[08:48]  * Laney does the 'rm fontconfig cache' trick to get emojis back in Chromium
[08:48] <Laney> why did I switch to Chromium like a month ago? I can't even remember any more, might go back to the nice Firefox deb :>
[08:52] <Laney> dear chromium, please exit when I exit you
[08:52] <seb128> Laney, if I understand that bug correctly it's snapd screwing the font cache which breaks deb apps as well (but maybe firefox doesn't rely on fontconfig for emoji?)
[08:53] <seb128> unless you do purge snapd along chromium which would fix the problem on your system
[08:54] <Laney> I never saw broken colour emoji anywhere else
[08:54] <Laney> but actually purging the cache didn't fix it in chromium either
[08:54] <Laney> 🤷
[08:54] <Laney> (^- that one is coloured for me)
[08:54] <seb128> callmepk, hey, you mentioned you had wslu SRUs waiting for sponsoring, do you have merge requests for packages for those?
[08:55] <Laney> Firefox works
[08:55] <seb128> Laney, I was commented based on https://bugs.launchpad.net/ubuntu/+source/chromium-browser/+bug/1858636/comments/31 also the noto-color-emoji is missing from the fontcache
[08:55] <seb128> so I don't understand why it doesn't impact e.g gnome-characters
[08:55] <Laney> maybe I have a different problem then
[08:56] <seb128> speaking of that bug
[08:56] <seb128> jamesh, ^ the snapd team bounced back to us, could you maybe help and reply to some of the questions for Ian on the bug?
[08:57]  * jamesh looks
[08:59] <seb128> jamesh, start reading at comment 37
[09:00] <seb128> before it's noise of users and triager trying to understand what's going on and how to trigger the issue
[09:15] <jamesh> seb128: I suspect the problem is down to freetype versions: I think snapd is running bionic's version of fc-cache statically linked against xenial's freetype
[09:16] <seb128> :/
[09:16] <seb128> why are they not using versions from the same serie?
[09:17] <seb128> also any easy way to confirm that? would be nice if snaps logged the fc-cache output
[09:17] <jamesh> it's trying to build binaries that will run against the core snap's libraries
[09:17] <jamesh> I think they assumed the cache differences were only down to fontconfig versions
[09:18] <jamesh> I've got a general idea about how we can handle this better with private fontconfig caches for snaps, but haven't built the prototype yet
[09:18] <seb128> k
[09:19] <jamesh> this would be roughly one cache for each gnome platform snap we publish
[09:19] <seb128> jamesh, thanks, that's useful input ... can you comment that on the bug?
[09:19] <jamesh> I'm writing the comment now
[09:19] <seb128> great
[09:19] <seb128> thx again!
[09:19] <seb128> Trevinho, did you notice that the bionic SRU for bug #1793496 failed to build?
[09:20] <seb128> not only that bug, it's just the one reference, but that's the update to a git snapshot you did
[09:32] <jibel> Laney, is there a way to simulate an rst drive in a vm?
[09:32] <jibel> I want to test the rst code of the installer
[09:34] <seb128> jibel, ubiquity/plugins/ubi-prepare.py:        return os.environ.get('SHOW_RST_UI', '0') == '1'
[09:34] <seb128> try setting that env maybe?
[09:35] <seb128> well, depends if you just want to see the page or actually test the detection of the disk I guess
[09:36] <jibel> sounds like what I need. I'll have a look. However I want an RST drive and another that is not to verify that you can install on the second drive even if the first is bitlocker'd
[09:37] <jibel> otherwise I'll play with the code a bit
[09:41] <Laney> jibel: not that I know of, no
[09:42] <Laney> Hack the detection code to return true for one of the drives or something
[09:43] <jibel> yeah, i'll do that
[09:43] <jibel> not really sru'ish but well...
[09:46] <Laney> ah for testing instructions?
[09:46] <Laney> maybe having an env var to do that would be good
[09:47] <Laney> UBIQUITY_PRETEND_DRIVE_IS_RST=...
[09:59] <ricotz> good morning desktopers!
[10:00] <ricotz> seb128, hi :), could you process https://launchpad.net/ubuntu/+source/nodejs/12.18.0~dfsg-3ubuntu1 which is in NEW
[10:10] <seb128> ricotz, hey ricotz, k
[10:12] <ricotz> seb128, thank you
[10:12] <seb128> yw!
[10:47] <seb128> ricotz, bug #1885006 is something for you or for Olivier when he's back?
[10:52] <ricotz> seb128, thanks, this looks like an issue for both of us which would hit firefox 79 beta
[10:53] <seb128> ricotz, I will drop an email to Olivier so he saws it once he's back
[11:08] <ricotz> seb128, looks like a simple variable rename of upstream, so an easy fix
[11:08] <seb128> ricotz, great!
[11:09] <seb128> ricotz, do you have an easy way to flag that to Olivier or should I better drop him an email as a FYI?
[11:10] <ricotz> I can leave a comment in the bug report point to the fix
[11:11] <seb128> ricotz, thx
[11:32] <seb128> Laney, did you see the discussion on #debian-gnome about our geoclue delta the other day? do you have any opinion on that?
[11:32] <seb128> I'm pondering just dropping the delta and syncing back
[11:32] <Laney> seb128: I did but it seemed Simon handled it with you so I didn't think about it much
[11:33] <Laney> let me see what the delta is
[11:33] <seb128> Laney, it's making the lib depends on the service
[11:34] <Laney> this is something from me from a few years ago
[11:35] <Laney> did bigon say anything about adding it?
[11:36] <Laney> I think it still makes sense, but it could maybe be a recommends as most apps which use geoclue can work ok without it
[11:36] <Laney> that amazon launcher probably should have been made to not crash
[11:36] <Laney> ah I forgot bigon is in here :>
[11:40] <seb128> Laney, we discussed on #debian-gnome if you have the backlog of 2 days ago (iirc) but summary is that him and Simon think it's better to let the apps that need the service recommends/depends on it
[11:40] <seb128> Simon's argument was that most GNOME components that links again the lib don't really need the service
[11:41] <seb128> e.g calendar, initial setup, settings-daemon
[11:41] <Laney> the way I read that conversation they both mentioned recommends
[11:42] <seb128> from the lib to the service?
[11:42] <Laney> yes
[11:42] <seb128>  <smcv>	seb128: in cases like libdbus-1-3 Recommends dbus, we still get occasional complaints about "installing $app pulled in $service, this is GNOME bloat"
[11:42] <seb128> so yeah, that discussion has argument for ang against the recommends
[11:43] <Laney> but libdbus still does have that recommends so ...
[11:43] <seb128> it feels like we failed to have a conclusion at the end, I will ask bigon again
[11:43] <Laney> that was a mention of what sometimes happens
[11:43] <seb128> well just did I guess :p
[11:43] <seb128> right
[11:45] <seb128> Laney, thx, I try another round to see if the recommends could be added in Debian
[11:46] <Laney> silly non team maintained packages!
[11:46] <Laney> I would have done something about it in 2017 otherwise :p
[11:46] <seb128> :-)
[11:53] <bigon> for https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=834176 I think I will close it as wontfix, there is no reason that the -dev pkg needs the daemon
[11:54] <bigon> for https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=864305, I guess a patch that conditionally add the Depends/Recommends for ubuntu is fine as a 1st step
[11:54] <bigon> was the m-a co-instability evalatuated?
[11:54] <bigon> TBH I'm way more annoyed by https://gitlab.freedesktop.org/geoclue/geoclue/-/issues/111 not being fixed
[11:55] <Laney> geoclue-2.0 should be foreign probably
[12:19] <ricotz> is someone able to do a simple runtime test of a firefox build on s390x?
[12:21] <ricotz> https://launchpad.net/~ubuntu-mozilla-daily/+archive/ubuntu/ppa/+build/19506686/+files/firefox-trunk_79.0~a1~hg20200625r537255-0ubuntu<IP_ADDRESS>~umd3_s390x.deb
[12:28] <seb128> bigon, right, that upstream issue is annoying :/ also I got no traction when I asked on our side about the BTS bug
[12:30] <bigon> Zeeshan said he will fix it "soon" but he's not opposed if somebody is doing it https://gitlab.freedesktop.org/geoclue/geoclue/-/merge_requests/70#note_528935
[12:30] <seb128> take over :)
[12:33] <seb128> ricotz, it starts fine, compared to the archive version that segfaults
[12:34] <ricotz> seb128, that is quite something then :)
[12:36] <seb128> :-)
[12:57] <jibel> xnox, I'm verifying bug 1847898. I created a VM in legacy mode with 3 disks and selected to install on vdc. grub-install runs on the /dev/vdc.
[12:57] <jibel> But after installation the machine doesn't find a bootable device.
[12:57] <jibel> xnox, my test case is correct?
[12:57] <jibel> is there any information I should dig for?
[12:57] <jibel> ah actually wait
[12:58] <jibel> hm, to make it boot I've to set disk3 as the first bootable device
[12:59] <jibel> not sure it's specific to VMs
[12:59] <jibel> ^ WDYT?
[14:05] <xnox> jibel:  what is the drive order set in like libvirt / virsh / qemu command line?
[14:05] <xnox> jibel:  or like can you ask to bring up the boot menu, and select the third drive, it then should boot fine.
[14:06] <xnox> jibel:  multi-disk selection in bios is a bit unpredictable.
[14:06] <xnox> jibel:  unlike UEFI where  we create ubuntu entry, and order it to be first, even though it's disk3 install.
[14:06] <jibel> xnox, yes, it boots fine when I changed the drive order. It's more a pb with libvirt/qemu which didn't try all the available drives
[14:07] <xnox> jibel:  it does, if one passes more options to it.
[14:07] <xnox> jibel:  i use virt-manager, and i can tick which drives to try, and in which order. I think there are qemu cmdline options / xml for that too
[14:08] <xnox> jibel:  <boot order="1"/> inside the <disk></disk in xml
[14:08] <xnox> and let me check qemu cmdline options
[14:09] <xnox> jibel:  ,bootindex=2 on the -device .... stanza
[14:09] <xnox> then it will try them all, in the defined order.
[14:09] <xnox> jibel:  but grub-install matches the selected drive means we did the right thing!
[14:12] <jibel> indeed
[14:24] <jibel> 5.6 didn't improve my sound issues. I keep losing hdmi output and all that remains are dummy entries
[14:53] <ricotz> seb128, please don't forget about https://launchpad.net/ubuntu/+source/nodejs/12.18.0~dfsg-3ubuntu1
[14:54] <ricotz> (it is a required build-dep for firefox 78+)
[14:56] <seb128> ricotz, I know, Olivier asked me to get it uploaded before his holidays, I did the nagging and LocustusOfBorg uploaded
[14:57] <ricotz> seb128, ok, I thought you are on ArchiveAdmin duty today
[14:58] <seb128> ricotz, I'm not really doing archive days but I'm happy to process pings between other things
[14:59] <seb128> ricotz, binaries accepted now
[14:59] <ricotz> I see, thanks!
[14:59] <seb128> yw!
[14:59] <ricotz> maybe tweak this a bit - https://wiki.ubuntu.com/ArchiveAdministration#Archive_days
[15:24] <seb128> ricotz, it has a warning 'Warning /!\ This is currently being re-assessed to a more task oriented approach, rather than regular admin days. '
[15:24] <seb128> but yeah
[17:17] <Laney> see you monday!
[17:28] <luna_> Rolling Rhino :D
[22:37] <callmepk> seb128 I create a MR for wslu to fix the build issue, tested on 1804 and the build should work now


[03:17] <lotuspsychje> good morning
[18:07] <lotuspsychje> 2 more apps joined the resize bug list; bug #2064192
[18:07] -ubottu:#ubuntu-discuss- Bug 2064192 in gnome-shell (Ubuntu) "Unable to resize windows" [Undecided, Confirmed] https://launchpad.net/bugs/2064192


 Got caught going over twice the speed limit...
[00:07] <EriC^^> :D
[00:08] <DosTuMai> Cops were like, "you know how fast you were going?" My response was, "ummmmmmm. Speed limit?"
[00:09] <EriC^^> haha
[00:10] <EriC^^> o:)
[00:13] <DosTuMai> [01:09:28] <DosTuMai> ricearoni: I know you think you're cool and stuff™, but could you drop the caps?  It's shouting and the only people that type in all caps usually have issues outwitting door knobs.
[00:13] <DosTuMai> [01:11:18] <DosTuMai> ricearoni: How about you go fornicate with an electrical outlet? =]
[00:14] <EriC^^> lol
[00:17] <DosTuMai> They haven't banned me yet.   Took a while for someone to notice.
[00:39] <EriC^^> you got a pm?
[00:39] <DosTuMai> Not yet, just waiting for one.
[00:52] <EriC^^> ricearoni is a super troll
[00:53] <DosTuMai> Yup, no use trolling him.
[01:05] <DosTuMai> No, the modern mini is a BMW.
[01:06] <EriC^^> yeah
[01:23] <DosTuMai> I'll leave them be for now. Continue tomorrow.
[01:24] <EriC^^> :D
[01:29] <DosTuMai> https://drive.google.com/open?id=0B1XfDBb8toplaV9zZ3FiNnc0TnM
[01:38] <DosTuMai> Rebooting...
[02:46] <DosTuMai> Right... It's "sudo kill -9 brain" to sleep, right?
[02:49] <OerHeks> No command 'brain' found, did you mean:
[02:49] <OerHeks>  Command 'rain' from package 'bsdgames' (universe)
[02:49] <OerHeks>  Command 'train' from package 'libtrain-bin' (multiverse)
[02:49] <OerHeks> brain: command not found
[02:49] <OerHeks> oer@OerNest:~$
[02:50] <DosTuMai> Crap. "sudo service brain stop" maybe?
[02:51] <OerHeks> hehe, service not running
[02:51] <DosTuMai> fartu@fartu-Aspire-5315:~$ sudo service brain stop
[02:51] <DosTuMai> [sudo] password for fartu:
[02:51] <DosTuMai> brain: unrecognized service
[02:51] <DosTuMai> fartu@fartu-Aspire-5315:~$
[03:02] <DosTuMai> Okidoki, I just "sudo sleepingpills", that might help. I'm going to lie in bed in a dark room until I don't brain any more. Zaijian~ \o
[08:48] <lotuspsychje> good morning to all
[08:54] <lotuspsychje> http://news.softpedia.com/news/systemd-227-is-a-major-release-that-adds-a-lot-of-awesome-new-features-494014.shtml
[09:02] <lotuspsychje> cfhowlett: goooooood moooooorning!!!
[09:03] <cfhowlett> and you!
[09:14] <lotuspsychje> support is slow again :p
[09:14] <lotuspsychje> zzzZZZZzzz
[09:15] <lotuspsychje> !release
[09:15] <ubot5`> Ubuntu releases a new version every 6 months. Each version is supported for 9 months to 5 years. More info at https://wiki.ubuntu.com/Releases & http://wiki.ubuntu.com/TimeBasedReleases
[09:15] <lotuspsychje> 2 weeks to go
[09:42] <lotuspsychje> morning EriC^^
[11:58] <BluesKaj> Howdy all
[12:06] <OerHeks> Heya BluesKaj
[12:07] <BluesKaj> Hi OerHeks
[12:16] <DosTuMai> o7
[12:51] <OerHeks> 3.19.0-31 and 3.13.0-66 problem-day
[12:56] <EriC^^> ah
[12:56] <OerHeks> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1503842 and https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1503655
[12:56] <ubot5`> Ubuntu bug 1503655 in linux (Ubuntu Wily) "duplicate for #1503842 Kernel bug in eventpoll_release_file+0x46/0xa0 with 3.13.0-66.107" [Undecided,Confirmed]
[12:56] <ubot5`> Ubuntu bug 1503655 in linux (Ubuntu Wily) "Kernel bug in eventpoll_release_file+0x46/0xa0 with 3.13.0-66.107" [Undecided,Confirmed]
[12:59] <OerHeks> another bug http://www.businesscat.happyjar.com/
[12:59] <OerHeks> fix that asap
[12:59] <DosTuMai|Sianz> Odd: Linux fartu-Aspire-5315 3.16.0-50-generic #67~14.04.1-Ubuntu SMP Fri Oct 2 22:08:53 UTC 2015 i686 i686 i686 GNU/Linux
[13:00] <DosTuMai|Sianz> That's probably why I'm not experiencing problems. This laptop is really sensitive to slight bugs.
[13:01] <EriC^^> 3.16 is a utopic kernel right?
[13:01] <OerHeks> vivid
[13:01] <DosTuMai|Sianz> Yus.
[13:01] <EriC^^> isn't 3.19 vivid?
[13:01] <EriC^^> you should upgrade to 15.04 DosTuMai|Sianz
[13:01] <OerHeks> errr i am wrong
[13:02] <OerHeks> ouch, still on utopia ...
[13:03] <EriC^^> OerHeks: what do you mean by fix that asap? do you think im a dev or something? :D
[13:05]  * OerHeks was pointing to businesscat
[13:05]  * EriC^^ checks the link
[13:06] <EriC^^> lol
[13:06] <EriC^^> :D
[13:07] <OerHeks> sorry, i should not mix real- with personal bugs
[13:08] <OerHeks> * even if it may affect you too
[13:09] <DosTuMai|Sianz> Okidoki, wish me luck, I'm upgrading.
[13:33] <DosTuMai> I thought, go get some eggs, the upgrade will be done. Nope, it's still going...
[13:35] <EriC^^> :D
[13:36] <DosTuMai> Anyways, new mic needs testing...
[13:40] <DosTuMai> It works!
[13:44] <DosTuMai> Anyone a radio DJ here? I'm recording sweepers.
[13:52] <EriC^^> cool
[13:57] <DosTuMai> No, not really. I'm being forced by a rogue AI to record her a sweeper, so thought I'd record more...
[14:07] <EriC^^> what for
[14:07] <EriC^^> what's an AI
[14:07] <DosTuMai> Friends that are DJs. O_o
[14:08] <EriC^^> what's it stand for?
[14:08] <DosTuMai> Y'know those, "hi this is [person], and you're listening to [DJ] on [radio station]."
[14:08] <EriC^^> ah yeah
[14:09] <DosTuMai> Rogue AI? Artificial Intelligence. It's a joke because DJ Toaster uses a sexy robo-voice.
[14:09] <EriC^^> oh ok
[14:12] <EriC^^> sounds like fun
[14:12] <EriC^^> what kinda music do you like
[14:13] <DosTuMai> Umm, most? xD
[14:14] <EriC^^> :D
[14:14] <DosTuMai> Jazz, swing, rock, metal, dubstep, drum & base, classical, opera, show tunes, prog rock, thrash, melodic rock, trance, Johnny Cash.
[14:14] <DosTuMai> And then some.
[14:15] <EriC^^> cool
[14:16] <EriC^^> any good dubstep you'd recommend?
[14:21] <DosTuMai> Check out Soundcloud.com FeedMe, obviously Skrillex, LukHash does some good dubstep... Ummmm, so many.
[14:21] <EriC^^> ok thanks
[14:22] <DosTuMai> Check out DalaDubz, too. He does some real good tunes.
[14:25] <EriC^^> thanks
[15:25] <DosTuMai> Taking. Forever. o_o
[15:28] <OerHeks> bleh .. stupid kernel update ruins a lot of machines.
[15:28] <DosTuMai> It's probably going to kill this. xD
[15:28] <Aphotica> Which kernel?
[15:28] <OerHeks> hmmm maybe yes
 3.19.0-31 and 3.13.0-66 problem-day
[15:29] <OerHeks> [14:56:00] <EriC^^> ah
[15:29] <OerHeks> [14:56:48] <OerHeks> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1503842 and https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1503655
[15:29] <ubot5`> Ubuntu bug 1503655 in linux (Ubuntu Wily) "duplicate for #1503842 Kernel bug in eventpoll_release_file+0x46/0xa0 with 3.13.0-66.107" [Undecided,Confirmed]
[15:29] <ubot5`> Ubuntu bug 1503655 in linux (Ubuntu Wily) "Kernel bug in eventpoll_release_file+0x46/0xa0 with 3.13.0-66.107" [Undecided,Confirmed]
[15:29] <TJ-> Why are those reported against Wily?
[15:30] <OerHeks> I don't know, ubottu is confusing
[15:31] <OerHeks> it is duplicate, so affects more than one version, trusty and vivid. not sure if wily is affected too.
[15:32] <TJ-> Oh, I rememeber this one. Andy merged a bad patch for aufs3
[15:32] <Aphotica> Waiting for MATE to fix the panel issue. There used to be a subtle border and now it's gone. Looks weird. I wonder if Ubuntu MATE will have it fixed.
[15:33] <Aphotica> MATE is supposed to be coming to Wayland, too. Though it may get Mir first. I dunno. Depends on Canonical.
[15:40] <DosTuMai> Just had 2 errors whilst upgrading... make that 6.
[18:47] <DosTuMai> Bwahahaha.
[20:24] <lotuspsychje> good evening to all
[20:26] <wileee> howdie
[20:27] <lotuspsychje> hi wilee
[20:29] <wileee> how is the other half of the world, heh, 1:30 pm here
[20:29] <wileee> west coast US
[20:29] <lotuspsychje> 22h29 here :p
[20:30] <OerHeks> oh, 22:29 here too ..
[20:31]  * OerHeks looks out of the window
[20:31] <lotuspsychje> lol
[20:31] <wileee> legalized cannabis here now, the news showed lines of people at the medical dispensaries, been a week since official
[20:32] <wileee> lines outside and around the block, lol
[20:32]  * lotuspsychje runs to the drug store
[20:33] <OerHeks> When they legalize it, the fun is over.
[20:34] <lotuspsychje> secret stash :p
[20:37] <wileee> I missed the fun had n need here.
[20:37] <wileee> no*
[20:58] <lotuspsychje> http://news.softpedia.com/news/false-rumors-about-microsoft-buying-canonical-are-ridiculous-494083.shtml
[20:58] <lotuspsychje> lol
[20:59] <lotuspsychje> if anyone wanna tryout unity8 live iso: http://news.softpedia.com/news/unity-8-all-you-need-to-know-494057.shtml
[21:35] <lotuspsychje> nite nite all


[11:37] <daftykins> happy weekendings
[11:38] <zxmpi> merry saturdaying
[12:29] <penguin42> yawwwwnnns
[13:36] <zxmpi> oh goodie, my new cdo keyboard arrived :-P https://i.redd.it/ms24xmnyhmp71.jpg
[13:54] <penguin42> oh weird
[13:55] <penguin42> odd punctuation placement as well
[13:56] <zxmpi> well when you've changed every other keys placement it seems a shame not to move them
[13:57] <penguin42> I wonder if it started out as French layout
[13:58] <zxmpi> the accents on the number row suggest somewhere non english speaking
[13:59] <penguin42> but I think it's only the French who are mad enough to have shifted numbers
[18:11] <m0nkey_> zxmpi: what is that horror?
[18:12] <zxmpi> someone posted it on reddit as an artwork
[18:37] <daftykins> :S
[21:56] <m0nkey_> daft question, but is there a release of ubuntu that doesn't have snap enabled by default?
[21:57] <m0nkey_> or should i embrace snaps and not worry about it?
[21:58] <m0nkey_> and can I move /home/$user/snap to something like /home/$user/.snap .. I like a clean home dir
[21:58] <daftykins> kubuntu doesn't have it, at least in 20.04 - no idea about newer
[22:01] <m0nkey_> that's kde, right? .. i'm not a fan if it is. i much prefer gnome.
[22:01] <daftykins> blech then you're stuck with their sauce!
[22:01] <daftykins> at least i am led to believe it relies on it, i just purge snapd when i see it
[22:02] <m0nkey_> i'll try it in a vm
[22:37] <m0nkey_> de-snapifying wasn't difficult
[22:37] <m0nkey_> nothing broke, which is good
[22:37] <m0nkey_> lol. but the store is gone, so there's that.
[22:37] <daftykins> \o/
[22:37] <daftykins> that's a plus
[22:39] <m0nkey_> it's a simple process, remove all snap packages, remove snapd and the gnome plugin.. put the snapd package on hold in apt, reboot and done.